Note: pyinstall has been renamed to pip
Ever been frustrated with easy_install? Interested in an alternative? Then you should go over to my work blog and read pyinstall: A New Hope.
Automatically generated list of related posts:
- pyinstall pybundles Update: pyinstall has been renamed to pip (per the suggestions...
- pyinstall is dead, long live pip! I’ve finished renaming pyinstall to its new name: pip. The...
Ian, that’s so great! Finally someone is starting to take care for this messy installer situation the Python community is in. If we now could also get a much clearer pattern or some kind of conventions of how to writes tests, documentation and so on creating new projects would be much easier. These secondary tasks are often a barrier for developers too. Thanks for your effort!
(Also posted to TOPP:)
Hi Ian,
This is great news! I’m sure a lot of people will want to use this.
A useful thing, by the way, would be some way to have to opt IN or at least verify with a yes/no prompt whether you want to install things into global site-packages. People do this far too often (e.g. they’re on Windows or are too loose with sudo, or just think that’s the way things have to be done).
Also (I just can’t resist): “This is a seemingly small improvement, but the idea is to move requirements out of setup.py and into something that is managed separately from any library or package”. Sounds a bit like buildout. :-)
Cheers, Martin
Ian, how about renaming the script? I mean “easy_install” or “pyinstall” is all well and cool, but frankly nobody’s going to remember it. You don’t install eggs.
How about hatching them? Or using an egg basket from which you can hatch or break (because a sane way to uninstall eggs would be nice, too) your eggs?
Would it be too late to ask for
pyinstallnot to do, by default, the magic HTML parsing and URL following thateasy_installdoes? This has lead people to host packages on their own servers, or sourceforge, and these things tend to break at unpredictable moments. I’ve even seen it happen that people do upload the packages to PyPI, but for some reasoneasy_installstill wanders off to a site that’s in some link and gets the egg from there instead. For that reason a recent version of lxml couldn’t be downloaded a while back because a news item hadn’t been updated on the lxml homepage, causingeasy_installnot to find the tarball, even though it was right there in PyPI! Talk about surprising behavior!If the default would be to download from PyPI only this might encourage developers to upload their package to PyPI which could then present the information in a structured manner.
That said, it’s probably too late given that people would expect
pyinstallto be able to do whateasy_installcan do. Still, it would be worthwhile to consider such a “strict mode”.I would consider pyinstall an opportunity for more sane defaults, so +1 to Martijn’s suggestion. I think “stumble about looking for stuff mode” should be opt in, not opt out.
Martin
Hi Ian! I sat next to you at lunch at the most recent PyCon.
Way to go on pyinstall! It sounds quite promising. I say +1 to change the default to not “stumble around looking for stuff”.
Another thing for the wishlist, if it isn’t already there: it’d be good if pyinstall could be installed as a library and has a API. Then tools such as buildout can easily drive it.
Yes, pyinstall runs around finding versions like easy_install. This isn’t great. One thing that should make it better is that pyinstall logs more about why it follows links, and also keeps track of where a link came from (so you can track down its source). Without link following lots of things won’t install, and that seemed like a problem.
If there was a way of collaboratively annotating PyPI instead of relying on maintainers to always get it right (which they don’t) that might make it more feasible. Or, I suppose, you could have a –search-widely option, and otherwise be conservative, but I’m not sure about that. pyinstall has some other features to try to help with version stability.
And regarding using pyinstall programmatically, I considered noting that as an advantage. But it’s not an advantage quite yet, as there’s no way I can commit to an API at this point (I’d at least have to put some consideration into an API, and I haven’t really). The actual
main()function in pyinstall isn’t too terribly complex, though, and using pyinstall programmatically would happen at the same level of abstraction thatmain()uses.It will be great is I cand download the specific minimun versions of eggs required in setup.py, even is the requirement is tagged as [somemodule>=someversion]
Working in Pylons or Turbogears, I found many times that downloading newer versions automagically breaks my application, because of incompatible changes in newer versions of required eggs
Watching with anticipation
:]