Update: pyinstall has been renamed to pip (per the suggestions in the comments to this post)
I added pybundles to pyinstall very shortly before I announced pyinstall. I hadn’t actually tried it out that much. Since then I’ve made three more minor releases of pyinstall, and I think the bundle support is working pretty decently.
A .pybundle file is just a bunch of source code, all the source code you need to install some package(s). For instance, for Deliverance I’ve created a bundle file so you can do:
$ easy_install pyinstall virtualenv
$ pyinstall.py -E DeliveranceTest/ \\
> http://deliverance.openplans.org/dist/Deliverance-snapshot-latest.pybundle
This creates a virtualenv environment in DeliveranceTest/, unpacks all the source from the bundle, and installs all of it. It’s not magical — it still has to compile the source and move the files around — but it does mean just a single download, and the versions of everything that is installed aren’t going to change unless that bundle file is regenerated.
I’ve been thinking about some other features for pybundles, like post installation scripts. All of this has raised a problem though: pyinstall needs to be a two-level command, with commands like:
pyinstall.py
install
X
pyinstall.py
bundle
Y
pyinstall.py
freeze
req.txt
and of course the not-yet-implemented:
pyinstall.py
remove
Z
But pyinstall.py install does not read well. It’s not too late to rename the package (yet again), or just rename the script. Ideas?
Automatically generated list of related posts:
- pyinstall: A New Hope Note: pyinstall has been renamed to pip Ever been frustrated...
- pyinstall is dead, long live pip! I’ve finished renaming pyinstall to its new name: pip. The...
It doesn’t have to be a two-level command. You could have (and I’d much prefer)
pyinstall X
pyinstall –make-bundle Y
pyinstall –freeze req.txt
pyinstall –remove Z
Marius: that’s how it currently works. But it means that as I add an option only related to making bundles, it shows up in all the help, even though it’s only applicable to the application in a certain mode. This is fine at the moment, but if I plan to add more options to those other subcommands (and I do) it will make the options messy.
How about
pydeploy.py install ZRename accordingly the package too.
Pydeploy, as a package name, would differentiate better fromeasy_install. Also deployment suggests a more complex operation than (just) install.My 2 cents (before bailout :-)
Peter
I liked the suggestion of ‘egg’ in the other thread – and I think your response is splitting some mighty fine hairs..
But if you are adamant that this tool does Python things and not Egg things, then ‘Constrictor’ is a taxonomic synonym for Python:
or, Pythons are in the taxonomic suborder Serpentes, so
And both are completely absent from pypi at the moment.
pydeploy is good too. Less cutesy than my suggestions and more informative as a name.
thinking on laud:
well let it be enough … sorry if was thinking to laud :)
well meybe just two more
Ian: optparse lets you define option groups. You could have the help look like
E.g. the Zope 3 test runner does this.
pymanage
FWIW, I really like
pydeploy.py ...I also like the suggestion on comment #8, that help format looks really good.
One suggestion, might you have the first argument not start with ‘–’?
That would distinguish the “command” from the “option” (my taxonomy might not be right).
+1 for pydeploy
How about
pymaker?Hmm, that sounded a lot funnier before I wrote it down.
+1 for Marius’s suggestion, pyinstall with the –install the default flag.
Is there a reason that the program is named ‘pyinstall.py’ and not just ‘pyinstall’ – prefixing and suffixing the word install just makes me think of PyPy whenever I read the name …
-1 for pydeploy since too me at least, deployment also connotates additional responsibilites such as starting (or restarting) services and logging application installation and configuration changes (http://en.wikipedia.org/wiki/Software_deployment).
Snake/egg theme (a bit long to type though)
Python resources theme
In terms of my command line preferences, I like how Mercurial does it the best. Which is having a very short executable name, followed by a command/task, followed by option flags and parameters.
I suppose you could have a different executable name to the application name. Again how Mercurial uses
hg. So you could call it PyIncubator (or whatever you like). And have commands like this:Ok, one last suggestion. Give it a short name that has no meaning. Such as Pip.
I also think a short name would be the best. For Ruby it is “gem”, for Java “jar”… therefore I like the “pi” suggestion a lot.
But I could also imagine some metaphors like:
Or even better ;)
Get even more inspirations here: http://en.wikipedia.org/wiki/Monty_Python
I think I’m going to go with the name
pip— short, non-threatening, unused on PyPI and Debian. It also [means](http://www.urbanext.uiuc.edu/eggs/res02-definitions.html#4) “to break through or peck holes in the shell by the chick.” I’m not sure what that metaphor means in this context, but it offers something for people to project upon.“pip installs packages”
Thanks Molasses!
Well then you might add an ‘y’ to get ‘pipy’. You have to have ‘py’ somewhere, its the union rules :)
pip looks good or what about pyp? it goes well with pypi also…
pyp(i) => python package (index)
pyp install (python package install)
Great work, I really hope this idea sprouts wings!
+1 for pip
+1 for non-pre-hyphenated commands (install, remove, bundle, etc.)
+1 for non-stumble-upon package search mode by default
Excellent work Ian. I’m hoping this project grows.
I’m also hoping to try it out with my own home-grown virtualenv-like project setup to see if it meets all of my current requirements, or if I can add anything useful to the conversation.