Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update or remove warning when namespace package doesn't use declare_namespace() #12

Closed
ghost opened this issue Jun 3, 2013 · 4 comments
Closed
Labels

Comments

@ghost
Copy link

@ghost ghost commented Jun 3, 2013

Originally reported by: adrian (Bitbucket: adrian, GitHub: adrian)


When building a namespace package, Setuptools checks (by searching in the code) whether the __init__.py therein calls declare_namespace from pkg_resources. If it doesn't it, it logs a warning, emitted here, which reads:

WARNING: (package) is a namespace package, but its init.py does not declare_namespace(); setuptools 0.7 will REQUIRE this! (See the setuptools manual under "Namespace Packages" for details.)

First of all, setuptools 0.7 now exists, so the future tense is somewhat worrisome. Also, I'm not sure whether requiring a declare_namespace call is actually in the plans anymore. (My package, for example, accomplishes namespace packages using pkgutil.extend_path from the standard library instead.) Some clarification, either in the warning or the docs, about what the plans are here would be helpful.


@ghost
Copy link
Author

@ghost ghost commented Jun 3, 2013

Original comment by adrian (Bitbucket: adrian, GitHub: adrian):


It's worth noting that this is sort of the opposite warning from what's being discussed in #2 (I think).

@ghost
Copy link
Author

@ghost ghost commented Jun 3, 2013

Original comment by jaraco (Bitbucket: jaraco, GitHub: jaraco):


Good find. Yes, it does say that, but setuptools 0.7 is now meeting a different goal, and if there was code that removed the compatibility and warning, it's not part of this 0.7 release. I'll comb through the 'setuptools' branch (which was not merged and was originally slated for 0.7) and see if there's a corresponding changeset.

Secondarily, we need to determine what's the proper thing to do about this warning and behavior. If it should be kept, it should be slated for setuptools 1.0 or later major increment release (per semantic versioning).

I seem to think pkgutil.extend_path and pkg_resources.declare_namespace meet similar goals but from a different perspective. My hunch tells me that if the package is declared to be a namespace package (in the metadata), that's a setuptools feature and may be enforced by setuptools. I'll have to learn more.

In the meantime, if anyone can shed some light on the issue, please feel free to do so.

@ghost
Copy link
Author

@ghost ghost commented Feb 9, 2014

Original comment by jaraco (Bitbucket: jaraco, GitHub: jaraco):


I found the original changeset in the setuptools 0.7 branch: f3c5c1984206

I've since grafted that change to the master. This change will force a 3.0 release to signal backward incompatibility.

@pje Are you aware of any issues with moving this intention forward other than the obvious backward incompatibility (which has long had a warning)?

@ghost
Copy link
Author

@ghost ghost commented Feb 9, 2014

Original comment by pje (Bitbucket: pje, GitHub: pje):


I don't see any issues with it, but to properly support PEP 420-style namespace packages (Python 3.3+), there are more changes needed. Notably, setuptools needs to be able to handle packages without an __init__.py, and to thus not do its special __init__.py handling for them. In addition, declare_namespace() is going to need to be a lot smarter. These are not really issues with this, though.

@ghost ghost added major bug labels Mar 29, 2016
@ghost ghost closed this Mar 29, 2016
jaraco added a commit that referenced this issue Dec 7, 2020
* Require toml extra for setuptools_scm

setuptools_scm does not know to invoke itself
if it can't read pyproject.toml.  This broke
sdist installs for projects deriving from skeleton:

  $ python -m pip install zipp --no-binary zipp
  Collecting zipp
    [...]
  Successfully installed zipp-0.0.0

Note the version number defaulting to '0.0.0'.
Building locally only works because pep517,
the build tool, depends on toml which it exposes
to the build environment.

* Require setuptools_scm 3.4.1 at a minimum

A bare

  [tool.setuptools_scm]

does not work in 3.4.0.

* fixup! Require toml extra for setuptools_scm

* fixup! Require setuptools_scm 3.4.1 at a minimum
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
0 participants