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

Have ez_setup.py default to current version on PyPI #215

Closed
bb-migration opened this Issue Jun 3, 2014 · 8 comments

Comments

Projects
None yet
1 participant
@bb-migration

bb-migration commented Jun 3, 2014

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


I'd like to consider having the ez_setup.py bootstrap script always download the latest version from PyPI by default, rather than hard-coding the default version in the script itself.

Instead of using the hard-coded version, it will connect to PyPI to determine the latest version from the JSON API if no specific version is provided.


@bb-migration

This comment has been minimized.

bb-migration commented Jun 15, 2014

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


Speaking of, the current ez_setup.py points to 4.0.1, which is 404 on PyPI.

@bb-migration

This comment has been minimized.

bb-migration commented Jun 15, 2014

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


@QuLogic That's a separate issue, #214

@bb-migration

This comment has been minimized.

bb-migration commented Jun 15, 2014

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


You could do what pip does, our bootstrap script just ships a copy of pip which it adds to sys.path and then uses that to install itself.

To be honest if you wanted it would be trivial to have a second copy of the pip bootstrap script which just installs setuptools and not pip + setuptools.

@bb-migration

This comment has been minimized.

bb-migration commented Jun 15, 2014

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


Setuptools used to do something similar by using an executable zip egg as the installer. I think one goal of the ez_setup.py is that it's also importable and usable by other packages to install setuptools on demand if it's not present. As a result, ez_setup.py has a goal to be a single, small text file.

I'm intrigued by the possibility of using the pip bootstrap script to install only setuptools. At over 100x the size, though, I'm disinclined to consider it as a replacement for ez_setup.py.

Could pip follow a similar process to bootstrapping that ez_setup.py does, namely relying on system-provided tools for secure download and distutils to install the necessary projects?

@bb-migration

This comment has been minimized.

bb-migration commented Jun 15, 2014

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


So really it comes down to how do we fetch the file we want to install. Once we have one of the packages available they are able to be installed regardless since both setuptools and pip supports some method of self installation with no other dependencies (setuptools using itself, pip using a wheel).

The pip bootstrap script includes pip because interacting with a repository is part of pip's functionality and to do that without pip would be reinventing parts of pip inside of the bootstrap script. For instance things like proxy support, alternative indexes, find links, additional certificates, etc are all things that just work with the current pip bootstrap script. Looking at ez_setup.py it supports none of these things, even those that setuptools itself supports. It could be made to support them, but at some point you've gone to a great deal of trouble to replicate the index accessing portions of pip/setuptools within the bootstrap script.

Beyond that there is also the issue of selecting the latest version, the pip bootstrap script defaults to the latest version of pip that it can discover. This ensures people get the latest version of pip even if they have an old copy of the script they are using. There's really not a good way of implementing that without reimplementing parts of pip/setuptools. This ticket mentions using the JSON API, however that means that someone cannot use this bootstrap script with a setuptools (or theoretical pip) hosted on a private index. The pip bootstrap handles this without any effort because it just uses pip. To do that inside of a smaller file would involve implementing link parsing and version parsing/sorting which is again already implemented.

I totally get the desire for a smaller file (although I don't really think that people should be putting ez_setup into their setup.py's anymore TBH) but for me, losing all of the features that we get from using pip to bootstrap pip is just too great of a cost to save a a MB worth of download.

@bb-migration

This comment has been minimized.

bb-migration commented Nov 16, 2014

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


I don't really think that people should be putting ez_setup into their setup.py's anymore

I agree. I've filed #286.

@bb-migration

This comment has been minimized.

bb-migration commented Nov 16, 2014

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


@dstufft The other major advantage to the ez_setup.py script is that it updates automatically when a new release of setuptools is made. As you recall, this is a feature we painstakingly engineered through several iterations. It's something that should happen mechanically as part of a release, but also something that's easy to roll back if there are issues with a particular release. Could we mechanize the process of vendorizing a particular release of setuptools into the pip bootstrap script?

@bb-migration

This comment has been minimized.

bb-migration commented Dec 16, 2015

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


I've decided to take a stab at supporting this (16007a2 and subsequent commits). Ultimately, it only took a few extra lines of code (23), but it saves a great deal of management keeping that script up-to-date with releases. Users are welcome to tweak that script to replace "LATEST" with their preferred default version or to supply an explicit version, either approach will bypass this new behavior.

I also acknowledge that this approach doesn't address some of the shortcomings raised by dstufft, but I believe it does not exacerbate them either.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment