Confusion of a hobby programmer
Hi folks, lately i was wondering (again) if i should put my small python projects on pypi, and reevaluated (again) the required package-format. And quite frankly im confused (again) as so many times before. I count at least 5 major and 3 minor/alternative packaging-systems: * distutils * distutils2 (=packaging?!) * setuptools * easy_install * distribute # bento # pip # zc.buildout A quick search-engine consultation brought results dated from 2009 to *early* 2012 in the top-ten, where the 2009ish results were not easily recognized as outdated and ranked mostly before the newer ones. (e.g. #4:The Hitchhiker's Guide to Packaging: 2009, Tarek Ziadé. ) The next stop lead to the *official* (as in supposed guideline) python docs. But then it got me again. *setup.py* ?! I thought Ziade said 2011 something like: "No more setup.py!" (And if i recall correctly - wanted to be applauded for this achievment! ;-) ) So i postponed (again) my contributions - not really a loss for the world - but somewhat sad nevertheless. (And with growing respect i give my kudos to those, which allow me to use pip for their packages.) And i'm not bitching (o.k. maybe a little bit;-) ) about the still unresolved, non-trivial task of creating the perfect packaging-system. What i'm really so sad about is the missing, or rather misleading and confusing pointer(s) for new pastry-chefs willing to contribute to the cheese-cake-shop as what to do. Maybe i'm just too dumb, to get it straight in one go, but on the other hand even Forest Gump build abundance and a rich empire out of his good-will, because he had the benevolent guidance of those smarter then him. Why am i denied this oppurtunity? As it turned out it seems i'm not the only one. A friend of mine wanted to contribute some rather particular applications and libraries, which he wrote for his experiments for his Ph.D.-Thesis, but gave up after he couldn't figure it out how to do it right in one afternoon. He felt discouraged by the circumstance, that he need more time to figure out how to make a package, then to actually write his tools. Or maybe he didn't want to admit he was embarrassed to need a higher IQ for simple packaging then for his doctoral thesis! ;-) So i figured out i'm not the only one, who prefers to relay on .tgz, .deb, or at least buildout redistribution as a personal packaging system, if not checking out directly from a cvs. So please, please fix at least the docs. I'm dreaming of a google-hit ranked: #1 python packaging primer for budding pastry chefs in five minutes. Your entry into the Cheese-shop aka pypi (Python Package Index) ... (p.s. don't look elsewhere except if searching for a python 2.7 guide!) Dated February 2012 - python 3.3 #2: python packaging primer for budding pastry chefs in five minutes. Your entry into the Cheese-shop aka pypi (Python Package Index) ... (p.s. don't look elsewhere!) Dated February 2012 - python 2.7 With heartfelt regards and in hope not to be a to big douche, Donny
OK, let's clear out some confusion.
On Mon, Feb 18, 2013 at 8:56 PM, Don Question
* distutils
Yes, this is the basic packaging system of Python, included in the standard library.
* setuptools
Extends distutils with many useful functions. However it is not under much development. Use Distribute instead.
* distribute
A fork of setuptools that sees more bugfixes. **Use this.**
# bento
An alternative packaging system not used very much. Probably fantastic, I haven't used it.
* distutils2 (=packaging?!)
In development, not of interest for you, will not be ready for years. The rest are not packaging systems.
* easy_install
Is not a packaging system, but a script that setuptools and distribute installs.
# pip
Not a packaging system but an installer. A better easy_install, if you like.
# zc.buildout
Not a packaging system.,
The next stop lead to the *official* (as in supposed guideline) python docs. But then it got me again. *setup.py* ?! I thought Ziade said 2011 something like: "No more setup.py!" (And if i recall correctly - wanted to be applauded for this achievment! ;-) )
Yes, that he said. You have been reading Tareks blog posts on the development and evolution of the future packaging that he put in a lot of energy in. But that's *future* and I'm pretty sure all his blog posts do explain that he talks about things that he was working on, not telling people that this is the state of packaging right now. However, the Hitchikers guide to packaging doe try to be a guide to packaging (hence the name). http://guide.python-distribute.org/ It uses distutils and also talks about Distribute.
And i'm not bitching (o.k. maybe a little bit;-) ) about the still unresolved, non-trivial task of creating the perfect packaging-system.
It's not non-trivial, it is impossible and will never happen. We'll get something that is better than what we have now, someday, but it will not be perfect. I don't really see what that has to do with making a package today. Essentially, you can either use distutils, or distribute which is distutils + a nuclear powered (and hence radioactive) suit, or if you are religious about these things, you probably want to use bento.
What i'm really so sad about is the missing, or rather misleading and confusing pointer(s) for new pastry-chefs willing to contribute to the cheese-cake-shop as what to do.
What pointers are that exactly? I've never seen anyone recommend anything else than Distribute or sometimes Bento for years, excluding the official Python docs, that obviously talk about distutils. //Lennart
I fell into this trap about a year ago, spending many hours reading documentation and blog posts, trying to use setuptools alternatives / get rid of setup.py. Turns out distribute + setup.py is still the most practical way to go. I approve of http://www.scotttorborg.com/python-packaging/ . It at least shows up when you search for "python packaging tutorial".
On 18 February 2013 19:56, Don Question
lately i was wondering (again) if i should put my small python projects on pypi, and reevaluated (again) the required package-format. And quite frankly im confused (again) as so many times before. I count at least 5 major and 3
You are right, the state of documentation is less than ideal. And sadly, searching the web turns up too much that isn't directly relevant to someone who just wants to package up a project. And *everything* is coloured by too much opinion and history. However, it's actually pretty simple. Read the Python documentation - "Distributing Python Projects" - which explains how to use distutils. It doesn't do a perfect job, but it's not bad. And distutils does fine for straightforward scenarios. Ask on this list of python-list if you have questions. You may well find that you don't need anything more than this. If you hit something that distutils can't handle (the most likely is that you want to include dependency handling in your build) you should look at distribute. Again the documentation (at http://pythonhosted.org/distribute/) is reasonably good - although it suffers from a tendency to "sell" distribute features rather than just documenting them. It has a number of useful extensions to distutils that may be exactly what you need. But really, a lot of packages don't need distribute. (Ignore setuptools, it's essentially an older version of what distribute now offers, but is otherwise identical). Also be careful with distribute - there are features in there (for example eggs) that are generally viewed as no longer best practice. My personal recommendation with distribute is to only use what you are sure you need. You should never need to go any further than this. There's other documentation round on the web, and lots of people willing to help, but you'll also get plenty of opinions and debate - and until you have some experience, it can be hard to evaluate that information, as you've found. Once you have more experience, you may want to venture further. You won't need to, but you might find that there are aspects of the basic tools that annoy you enough that you want to start looking for "better" alternatives. But by then you should have enough experience to make a judgement over what's helpful and what isn't. Sorry the picture isn't better - you're right, it should be - but stick to the basics, it's not too bad. Paul. PS The above is my opinion - and just as with anything else you hear, it's likely to be debated hotly by others. Take it for what it's worth :-)
participants (4)
-
Daniel Holth
-
Don Question
-
Lennart Regebro
-
Paul Moore