astropy-helpers and astropy

[Ole Streicher]

Hi,

I just got a request to package astropy-helpers for Debian. To do this
in an optimal way, I'd like to know how the relation between astropy and
astropy-helpers is: is the latter always a part of astropy, which is
just available separately as an option? Or does astropy just bundle the
(otherwise independent) helpers package?

So to say: will we have (in the foreseeable future) the case of an
updated astropy-helpers without astropy updated (or vice versa)? Or are
they guaranteed to match?

Shall I build the astropy-helpers package from the astropy source or
from the astropy-helpers source?

Best regards

Ole

[Erik Bray]

On Wed, Aug 20, 2014 at 5:40 AM, Ole Streicher <ast...@liska.ath.cx> wrote:
> Hi,
>
> I just got a request to package astropy-helpers for Debian. To do this
> in an optimal way, I'd like to know how the relation between astropy and
> astropy-helpers is: is the latter always a part of astropy, which is
> just available separately as an option? Or does astropy just bundle the
> (otherwise independent) helpers package?

astropy-helpers is a separate from Astropy. Astropy does not require
it to run--only to build the package and the documentation. Same
should go for any other package that uses it. It should never be a
run-time dependency of a package. (In other words, no package should
have Depends: astropy-helpers). There's no reason to. (I'm not sure
why it would even be packaged, though I guess it makes sense for doc
builds).

> So to say: will we have (in the foreseeable future) the case of an
> updated astropy-helpers without astropy updated (or vice versa)? Or are
> they guaranteed to match?
> Shall I build the astropy-helpers package from the astropy source or
> from the astropy-helpers source?

Each Astropy release is tagged to a specific astropy-helpers release.
However any astropy-helpers version with the same MAJOR.MINOR version
number should continue to work (the .MICRO is reserved for patch
releases).

I'm still not sure entirely what the purpose would be for packaging it
though, again, outside the case of documentation builds...

Erik

[Ole Streicher]

Erik Bray <erik....@gmail.com> writes:
> I'm still not sure entirely what the purpose would be for packaging it

It seems that the astroquery package needs astropy-helpers in order to
build it. So, it would need to have a "Build-Depends" on this package.

Similarly, the package would be of use for developers of astropy
affiliated packages.

Does this make sense to you? Or did I misunderstand the concept?

Best

Ole

[Erik Bray]

It does make sense. But part of having a separate astropy-helpers
package is that

1) Bugfixes to astropy-helpers can easily be released, and
automatically be picked up by users building the packages that use it
via the ah_bootstrap.py script.

2) Another aspect to astropy-helpers is that different affiliated
packages can depend on different versions of astropy-helpers. If I
release a new version tomorrow that's radically different (and I do
have plans to do that) and update Astropy to build with the new
version, it doesn't force affiliated package developers to update how
their packages are built--not immediately.

If a Debian package were made it would be a Build-Depends, but the
same version of astropy-helpers is not necessarily a dependency for
every package that uses it.

On the other hand there have only been two releases of astropy-helpers
so far (0.4.0 and 0.4.1) and only a couple other released packages
that are actually using it. So maybe my concerns are merely
hypothetical.

Erik

[Joseph Booker]

On Wed, Aug 20, 2014 at 10:56 AM, Erik Bray <erik....@gmail.com> wrote:

I'm still not sure entirely what the purpose would be for packaging it
though, again, outside the case of documentation builds...

Taken to an extreme, why package gcc? Every C/C++/etc package could have their own (potentially out-of-date, buggy) version in its source tree. Besides the time/space costs of this, the reasoning against it still applies.

Ole: astropy-helper-based packages try to build astropy-helper themselves (even downloading it if you don't use git submodule to grab it). This breaks the easyinstall sandbox Gentoo Ebuilds use, so a system install is used in the ebuilds I contributed to the gentoo-science repository. Are you running into similar issues with astroquery not able to build astropy-helpers in packaging on Debian?

[Erik Bray]

On Wed, Aug 20, 2014 at 11:13 AM, Joseph Booker <j...@neoturbine.net> wrote:
> On Wed, Aug 20, 2014 at 10:56 AM, Erik Bray <erik....@gmail.com> wrote:
>>
>> I'm still not sure entirely what the purpose would be for packaging it
>> though, again, outside the case of documentation builds...
>
>
> Taken to an extreme, why package gcc? Every C/C++/etc package could have
> their own (potentially out-of-date, buggy) version in its source tree.
> Besides the time/space costs of this, the reasoning against it still
> applies.

Bug patches aside, astropy-helpers also has an API and different
packages could be using different versions of that API. That's why
you do package multiple versions of gcc after all.

Worse comes to worse you'd have to do the same for astropy-helpers,
but as I understand it packaging multiple versions of a Python package
is a pain. Still, only a hypothetical concern at this point.

> Ole: astropy-helper-based packages try to build astropy-helper themselves
> (even downloading it if you don't use git submodule to grab it). This breaks
> the easyinstall sandbox Gentoo Ebuilds use, so a system install is used in
> the ebuilds I contributed to the gentoo-science repository. Are you running
> into similar issues with astroquery not able to build astropy-helpers in
> packaging on Debian?

Try running the setup.py with the --offline flag. That's what it's
there for (but could probably *still* be better documented *sigh*)

[Adam Ginsburg]

Apparently astroquery was bundeled with the wrong version of
astropy-helpers until about 20 minutes ago, so that may have caused
some problems.

> --
> You received this message because you are subscribed to the Google Groups "astropy-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to astropy-dev...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



--
Adam Ginsburg
Fellow, European Southern Observatory
http://www.adamgginsburg.com/

[Ole Streicher]

Erik Bray <erik....@gmail.com> writes:
> Bug patches aside, astropy-helpers also has an API and different
> packages could be using different versions of that API. That's why
> you do package multiple versions of gcc after all.
>
> Worse comes to worse you'd have to do the same for astropy-helpers,
> but as I understand it packaging multiple versions of a Python package
> is a pain. Still, only a hypothetical concern at this point.

So, there is still no stabilized API? Can one expect upward
compatibility? Of is it at least simple to patch a given package so that
it can be build with the installed version of astropy-helpers?

Also, just hypothetical questions. However, a need to support different
astropy-helpers versions in Debian would be a real pain.

Best regards

Ole

[Erik Bray]

On Wed, Aug 20, 2014 at 12:06 PM, Ole Streicher <ast...@liska.ath.cx> wrote:
> Erik Bray <erik....@gmail.com> writes:
>> Bug patches aside, astropy-helpers also has an API and different
>> packages could be using different versions of that API. That's why
>> you do package multiple versions of gcc after all.
>>
>> Worse comes to worse you'd have to do the same for astropy-helpers,
>> but as I understand it packaging multiple versions of a Python package
>> is a pain. Still, only a hypothetical concern at this point.
>
> So, there is still no stabilized API? Can one expect upward
> compatibility? Of is it at least simple to patch a given package so that
> it can be build with the installed version of astropy-helpers?

No, it is stable. I just have plans to rework it in the future. That
said, I think any future rework could still maintain backwards
compatibility with the current API. So again, thinkinking about it,
most of my concerns are hypothetical and not a problem now--especially
if having a proper package for astropy-helpers will make builds easier
for Debian. I just wanted to be clear about how this is used.

> Also, just hypothetical questions. However, a need to support different
> astropy-helpers versions in Debian would be a real pain.
>

I imagine so. I think we can avoid that :)

Erik