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
Rework namespace extension #218
Comments
@abravalheri, I am not sure anymore if we should really change this. I see no advantages except of the fact that they call it
much nicer. |
Yeah, I was reading the links you sent this morning and wondering the exactly same thing... Is |
@abravalheri Okay, then I think that we agree on the fact that the new |
So it seems that setuptools now provides a The main disadvantage in using it instead of I will re-open this issue, for investigation (specially because obviating pkg_resources is a milestone in setuptools, see #309) |
Since setuptools version 40.1 there is the |
Thank you very much @smartsammler! Nice to know that this works, it will probably be part of v4. Now the only thing I am not exactly sure is if we should always use |
Actually Sphinx did not work anymore correctly. To fix this one also has to provide the - cmd_line_template = "sphinx-apidoc -f -o {outputdir} {moduledir}"
+ cmd_line_template = "sphinx-apidoc --implicit-namespaces -f -o {outputdir} {moduledir}" (Maybe this information is helpful in case someone also want to use putup and then change to native namespaces). Unfortunately I don't know if |
Thank you very much @smartsammler, I think the best is to do the change you propose, and see if we have any feedback, but I suppose as long as we are using the |
@abravalheri So one really has to be aware of the implication that those two namespacing concepts aren't compatible with each other. So one has to update all projects once using the implicit namespaces, as far as I understood and experienced this. Some colleagues of mine for example had examples in |
Hi @smartsammler, I have provided a PR (#328) with the suggested fix and a bunch of new documentation on the topic. Please feel free to review it. My opinion is that we should move forward by being opinionated, but still providing documentation for people that want to preserve the old behaviour. Since I understand that some people may have particular use cases and I tried to cover as much as I could in the additional documentation in the PR. I hope that is enough. |
For the time being I will merge the PR, since there is a bug with the current v4.0.x branch and the PR fix it... |
Right now we historically use pkg-resource-style namespace packages. According to the official packaging guide this seems to be still valid but an outdated option. With version 4.0 we should break with this behavior and should start using the new native namespace packages as define in PEP 420 that requires Python 3.3 and above.
The text was updated successfully, but these errors were encountered: