-
-
Notifications
You must be signed in to change notification settings - Fork 7.9k
Make mpl_toolkits
a non-namespace package
#5327
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
Comments
actually, cc me to coordinate w.r.t. basemap now. I am taking over I agree with it in principle, I just don't know how we want to go about On Mon, Oct 26, 2015 at 3:53 PM, Michael Droettboom <
|
My idea was to look at what IPython/Jupyter was doing with there big split thing |
Please, PLEASE do this. I just spend most of the day figuring out a workaround for Spack, where every package is installed in a separate root. See: spack/spack#1964 You can see my pain here: spack/spack#1948 |
I added the milestone in the hope that this will raise the attention level, and maybe we can get it done. Unfortunately, I don't know exactly what it will entail. |
If you have to break the API, I'd go along with that. Changing scripts On Fri, Oct 7, 2016 at 3:07 PM, Eric Firing [email protected]
|
OK, I have a different suggestion... Rather than removing the use of namespace packages, why not just have Matplotlib follow the standard for them, which came into being with Python 3.3? (The only tricky thing is... it would have to follow the new standard when using Python 3.3 or later; but do what it's doing now for older Pythons). Looking in the Python changelog, I see that starting with Python 3.3, they support namespace packages in a standardized way: |
If I am not mistaken, we cannot follow the new way if we still support python 2.7. I don't think namespace packages bring anything useful on the table. scikit-learn was very happy to move out of the scikit namespace. |
That might be a reasonable temporary solution (if it can work with 2.7 some how) which is easier to implement. I sagree with @NelleV that we should get rid of the namespace package completely and
My main concern with this approach is what happens at upgrade time but on the other hand namespace packages as they currently are tend to result in upgrade issues anyway We also need to handle natgrid but that is only uses internally in matplotlib so it should be simple enough to handle or perhaps just remove. |
You would need to make one shim for Python 3.3 and above; and another shim On Tue, Oct 11, 2016 at 11:54 AM, Jens Hedegaard Nielsen <
|
This issue has been marked "inactive" because it has been 365 days since the last comment. If this issue is still present in recent Matplotlib releases, or the feature request is still wanted, please leave a comment and this label will be removed. If there are no updates in another 30 days, this issue will be automatically closed, but you are free to re-open or create a new issue if needed. We value issue reports, and this procedure is meant to help us resurface and prioritize issues that have not been addressed yet, not make them disappear. Thanks for your help! |
Closing as duplicate of #25244, as that's where discussion is happening. |
Namespace packages are the source of all kinds of user errors.
This would involve moving basemap (and any other 3rd-party packages that install into
mpl_toolkits
, if they exist) to the top-level and installing a shim so it could still be imported from the old location.Cc:
@jswhit@WeatherGod to coordinate.Cc: @jenshnielsen
The text was updated successfully, but these errors were encountered: