Ian Bicking: a blog

{ 11 }

Comments

1. perenzo | 24-Sep-08 at 1:11 am | Permalink

   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!

2. Martin Aspeli | 24-Sep-08 at 3:39 am | Permalink

   (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

3. Masklinn | 24-Sep-08 at 4:19 am | Permalink

   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?

4. Martijn Faassen | 24-Sep-08 at 6:16 am | Permalink

   Would it be too late to ask for pyinstall not to do, by default, the magic HTML parsing and URL following that easy_install does? 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 reason easy_install still 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, causing easy_install not 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 pyinstall to be able to do what easy_install can do. Still, it would be worthwhile to consider such a “strict mode”.

5. Martin Aspeli | 24-Sep-08 at 6:29 am | Permalink

   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

6. Zooko | 24-Sep-08 at 10:10 am | Permalink

   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”.

7. Martijn Faassen | 24-Sep-08 at 10:44 am | Permalink

   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.

8. Ian Bicking | 24-Sep-08 at 10:48 am | Permalink

   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.

9. Ian Bicking | 24-Sep-08 at 10:53 am | Permalink

   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 that main() uses.

10. Agustin Villena | 25-Sep-08 at 10:16 am | Permalink

    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

11. Tyler Oderkirk | 25-Sep-08 at 8:29 pm | Permalink

    Watching with anticipation :]

Post a Comment