Skip to content

#3389 breaks an affiliated package #3478

Closed

Description

@mdboom

pyasdf's setup.py ends up importing astropy.units for reasons that aren't entirely good (so I plan to fix that). But this worked until #3389, when astropy.units is no longer importable during setup, because:

When _ASTROPY_SETUP_ is in builtins (it's set in the setup.py in the package template) [1] the NUMPY_LT_X_X constants don't get imported into astropy.utils.compat [2], then when astropy.units.quantity tries to use one of those constants [3], it blows up.

[1] https://github.com/astropy/package-template/blob/master/setup.py#L16
[2] https://github.com/astropy/astropy/blob/master/astropy/utils/compat/__init__.py#L13
[3] https://github.com/astropy/astropy/blob/master/astropy/units/quantity.py#L24

Not sure how to resolve this other than requiring affiliated packages to be "careful":

There seems to be only one case where _ASTROPY_SETUP_ matters to affiliated packages:

https://github.com/astropy/astropy/blob/master/astropy/config/configuration.py#L665

Maybe we use a different variable for "affiliated package setup" vs. "astropy setup"?

Activity

  1. embray commented on Feb 10, 2015

    @embray
    Member

    I was a little bothered about the fact that those constants are undefined in that context. But it didn't break Astropy itself so I forged ahead. And it made sense as it was, since in _ASTROPY_SETUP_ it's assumed that dependencies like Numpy might not be available.

    What I could do is enhance the minversion function to accept a module name as a string instead of (or in addition to) an actual module object. Then it can handle the importing of that module, and if that fails just return False (since obviously the minimum version requirement has not been satisfied if the dependency doesn't exist at all).

  2. added this to the v1.0.0 milestone on Feb 10, 2015
  3. mhvk commented on Feb 11, 2015

    @mhvk
    Contributor

    @embray - I think the fix in #3479 is reasonable, but your logic above is not: if minversion returns False if the import fails, then all the strings NUMPY_LT_..., which are defined as some not minversion(...) will return True. Logically, I think one should let ImportError be raised.

  4. added
    Affects-devPRs and issues that do not impact an existing Astropy release
    on Feb 11, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Affects-devPRs and issues that do not impact an existing Astropy releaseBug

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions