-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Drop support for self upgrade/installation #581
Comments
I'd suggest you also put some official upgrade instructions in the readme and docs. I don't see anything there, and I see the usual conflicting advice on the internet. Same for pypi. I tried this, which I found in some comments here: |
The But you're right, the upgrade story needs to be well understood and documented. |
I hope it's clear that I was not recommending |
I have recently needed to install setuptools manually because pip couldn't do it. https://github.com/PyCQA/pyflakes/pull/76/files#diff-11c909939117928998b102a1fff7d363R33 |
I think it makes a lot of sense for a cleaner and consistent experience and clean separation of duties. It will make the overall package landscape more coherent: setuptools builds (and optionally installs from sources) eventually programmatically while pip bootstraps and installs. The only area where I can fathom a possible issue for some rare tools is the lack of a stable function API in pip when using it as a library. But even then, spawning a pip subprocess is not a big issue (instead of calling its functions) from Python and this is something I routinely do. |
@jayvdb let's be entirely forthright here, pyflakes needed to install setuptools manually on AppVeyor and pypy. That also should have been a separate bug report to fix that. It's related to this, yes, but not something that negates this goal. |
…ng nominal API compatibility for use_setuptools(<version>) and disabling download_setuptools and support for command-line parameters to the script invocation itself. Ref #581.
In the feature/581-depend-not-bundle branch, I've drafted an implementation that passes tests and installs nicely as a wheel. If you would like to try it out, for a limited time, the wheel of g767dcea0 can be installed as so:
|
hmm I think having it upgrade itself (as an optional configuration option) should be added and default to not set to do it. So that way those who prefers this self upgrades can do it but before it upgrades itself it checks for upgrades to the other dependencies instead of shipping them with setuptools. But wouldn't this break pip for a little while as some parts of pip use setuptools? So basically (as an optional config) have to self updates go in this order:
This way for those who (like me) does not always remember to pip install modules to know when there is a new version it would be easier to handle. Besides I have been working on things like this for my code so I dont have to remember to update them constantly to |
@AraHaan I don't think there's any way to achieve what you describe. Part of the problem is that Now if you're talking about as strictly In other words, it may be possible, but it's an awful lot of work and investment in a tool chain that's long been superseded by pip. If others wish to invest this effort, I won't resist it, but personally, my focus will be on pushing to the future rather than dragging forward the past. |
I've addressed the concern above about pyflakes on appveyor by providing a technique for getting pip installed and using that to install setuptools on pypy. I'm ready now to proceed with the release. I've been running the branch version of setuptools for some time now with success. I'd like to invite the community one last time to give this version a try and identify issues that may arise. Here's a link to the wheel: https://dl.dropboxusercontent.com/s/4wwpuzpg1ortmgn/setuptools-33.1.1.post20170116-py2.py3-none-any.whl Please try it out and identify any issues in your environment before I cut a release. |
Oh, and if you're using the |
This may be a silly idea, but it seems like with this branch it'd make sense to just deprecate and remove |
Not a silly idea at all. My goal was to be minimally invasive and provide a compatibility shim that would ease the transition and guide its users to the same conclusion (just use pip directly). I was particularly concerned about the bootstrap scenario, which invokes ez_setup.py through its API. They bundle ez_setup.py in their own bootstrap script. But now that you say it, it's probably the case that their bootstrap will fail at the implicit assumption that pip is installed, in which case it's no help. It seems to me the options are to provide an ez_setup.py script that tries to do the right thing or to break it down and have it do nothing but raise an error message that it's no longer supported. Leaving it in place as-is will only lead users to an error during the install, which will appear like a bug:
I'll go with the latter option and simply deprecate ez_setup.py. |
Not so much a suggestion but really just a statement that this is going to currently make installing setuptools via sdist via pip more annoying since people will have to manually install setuptools' build dependencies (since pip has no concept of that yet, and That being said, pypa/pip#4144 should hopefully land in the near future and allow setuptools to add a [build-system]
requires = [
"wheel",
"packaging>=16.8",
"six>=1.10.0",
"appdirs>=1.4.0",
] and pip will basically do what |
Yes, thanks for that clarification and reference. The expectation is that users will typically install from wheels and anyone who wants to install from sdist will need to prep the environment in advance. Glad to hear that PEP 518 support is coming to pip. |
@jaraco I feel like this also paves the way for splitting |
…tall and signal that the bootstrap script is deprecated. Ref #581.
As you can see ^ I've updated the bootstrap script to simply pin to the last version prior this new release, and that compatibility bootstrap script, while warning about the issue, should continue to support older environments. |
It's deprecated. See pypa/setuptools#581
* Add RIME op tensorflow source to MANIFEST.in * Deprecate ez_setup.py script See pypa/setuptools#581. * Include missing setup.cfg * Pin python-casacore==2.1.2 for now
Yes, one should do |
FYI, this completely messed up this tutorial and I don't know how to proceed: http://newcoder.io/begin/setup-your-machine/#windows https://github.com/econchick/new-coder How should the tutorial here be updated to reflect the changes? @econchik |
Thank you @The-Compiler, was just looking there... On this step: https://packaging.python.org/tutorials/installing-packages/#ensure-pip-setuptools-and-wheel-are-up-to-date
|
pypa/setuptools#581 Signed-off-by: Anders Kaseorg <[email protected]>
Downloaded from https://bootstrap.pypa.io/ez_setup.py (which is now deprecated) this corrects a failing build in travis. The overall ez_setup/setuptools strategy will need to be reviewed, taking pypa/setuptools#581 into account.
The version here [generates deprecations](https://app.circleci.com/jobs/github/usnistgov/fipy/2031) and [ez_setup.py itself is deprecated](pypa/setuptools#581)
The version here [generates deprecations](https://app.circleci.com/jobs/github/usnistgov/fipy/2031) and [ez_setup.py itself is deprecated](pypa/setuptools#581)
* Raise errors for DeprecationWarnings during CI tests * Remove ez_setup.py The version here [generates deprecations](https://app.circleci.com/jobs/github/usnistgov/fipy/2031) and [ez_setup.py itself is deprecated](pypa/setuptools#581) * Change "FORTRAN" array ordering to 'F' Missed in #707 * Update from deprecated Pysparse API This stuff was deprecated [ages ago](https://sourceforge.net/p/pysparse/git/ci/241a05d7a6e5f0f8ae28c53ac79a2111fe2d7cc0/) * Switch from itsolvers classes to krylov functions The itsolvers classes aren't written right (e.g., `solve()` doesn't return anything) and don't encapsulate anything we care about. The `krylov` calls are set up the way we expect. * Raise errors for DeprecationWarnings only in test suite Raising errors for all of `python setup.py test` causes errors for deprecations in things we don't control, like versioneer. * Use legacy absolute tolerance for scipy Krylov solvers Avoid DeprecationWarning * Introduce specialized TestProgram to throw Deprecation errors In Py3k, TestProgram makes it very hard to change DeprecationWarnings into errors. [TestProgram gives all warnings an action of `default`](https://github.com/python/cpython/blob/master/Lib/unittest/main.py#L84) which causes [TestRunner to clobber our DeprecationWarning filter](https://github.com/python/cpython/blob/master/Lib/unittest/runner.py#L167) (passing any other action to TestProgram just causes that action to clobber instead) * Force Py27 builds on Visual Studio 2015 scikit-fmm (and maybe others) needs VC++ 9.0 https://help.appveyor.com/discussions/problems/26278-organization-build-fails-because-vc-90-is-not-present * Choose appropriate build environment [Exclude unwanted build configurations](https://www.appveyor.com/docs/build-configuration/#exclude-configuration-from-the-matrix)
by default, the bootstrap script will install newest buildout, but starting with buildout 3.0.0, there is a problem of wheel like this: ez_setup.py is deprecated and when using it setuptools will be pinned to 33.1.1 since it's the last version that supports setuptools self upgrade/installation, check pypa/setuptools#581 for more info; use pip to install setuptools Downloading https://pypi.io/packages/source/s/setuptools/setuptools-41.6.0.zip Extracting in /tmp/tmpyglw2hza Now working in /tmp/tmpyglw2hza/setuptools-41.6.0 Building a Setuptools egg in /root/slapos.package/obs/slapos/sn_1.8.3+1.0.290+1/slapos/build/opt/slapos/eggs warning: no files found matching '*.py' under directory 'tests' warning: no previously-included files found matching 'pyproject.toml' /root/slapos.package/obs/slapos/sn_1.8.3+1.0.290+1/slapos/build/opt/slapos/eggs/setuptools-41.6.0-py3.9.egg Traceback (most recent call last): File "/root/slapos.package/obs/slapos/sn_1.8.3+1.0.290+1/slapos/build/opt/slapos/bootstrap.py", line 199, in <module> ws.require(requirement) File "/root/slapos.package/obs/slapos/sn_1.8.3+1.0.290+1/slapos/build/opt/slapos/eggs/setuptools-41.6.0-py3.9.egg/pkg_resources/__init__.py", line 900, in require File "/root/slapos.package/obs/slapos/sn_1.8.3+1.0.290+1/slapos/build/opt/slapos/eggs/setuptools-41.6.0-py3.9.egg/pkg_resources/__init__.py", line 786, in resolve pkg_resources.DistributionNotFound: The 'wheel' distribution was not found and is required by zc.buildout Impossible to build SlapOS, exiting. make: *** [Makefile:9: download_cache] Error 1
* ez_setup has not been updated in 7 years: https://github.com/pypa/setuptools/tree/bootstrap * See pypa/setuptools#581
* ez_setup has not been updated in 7 years: https://github.com/pypa/setuptools/tree/bootstrap * See pypa/setuptools#581
I'd like to consider dropping support for setuptools installing or upgrading itself, including the removal of the bootstrap script, and instead, rely entirely on pip for installation of setuptools. Doing so would (a) allow for the simple declaration of dependencies over vendoring them, (b) eliminate the need for a bootstrap process besides simple 'pip install', (c) eliminate the special handling for self installation, and (d) limit setuptools installation to the single-version installs that pip allows.
I expect some environments like bootstrap or other systems might be affected, so I'm cautious about this possibility. This ticket serves to host the conversation and considerations.
The text was updated successfully, but these errors were encountered: