On 2/20/07, primco <[EMAIL PROTECTED]> wrote: > > > I think this would be a promising solution for bundling up Pylons with > > > your app for redistribution if the complexity was hidden. I'm not > > > great at setuptools and very wary of > > > thishttp://cheeseshop.python.org/pypi/zc.buildout > > > page. Those instructions are crazy. Do they expect normal humans to > > > use this tool if your day job isn't professional setuptools package > > > manager? > > > > I've tried to use zc.buildout a couple times. It's pretty complex, and > > I felt like I spent a lot of time debugging my build. It does make it > > possible to do things like build other kinds of software (with > > configure/make/make install). But building other software doesn't > > actually make all the software work together, so I was unimpressed -- > > it's useful if you want to build MySQL or Apache, but if you want to > > build a C library and get it linked together, it's not easy. > > If you try it, note that it won't install scripts unless you tell it to > > install the package (i.e., PasteScript) -- including it as a dependency > > won't include the script. You might have to jump through some other > > hoops too. > > What's your feeling about PJE basically saying workingenv was an > unsupported hack? He seems to back the approach of zc.buildout more. > In the posts I've read, PJE seems to recommend using only the > setuptools features to get isolated package installs. To me, the lower- > level approach you've taken that deals with the platform-specific > issues inherent in python is more straightforward (although to a > newbie, all the site.py hacking is probably bewildering). > > This may be off topic but I keep running into these issues with Pylons > because of the large number of dependencies and rapid changes in the > versions of software throughout the dependency tree. I've been forced > to learn more about setuptools than I'd like just to manage my > development environment and release process in a way I'm comfortable > with. You can't always run off the head revision of 15 packages. At > some point you have to freeze it and release it.
I have no answers but this is an important topic, and if there's not a panel discussion about it at PyCon, there should be. I've used workingenv and virtual-python enough to realize they do fill an important need, especially with packages that have so many dependencies as Pylons. I use workingenv when I can and virtual-python when I really, really want more isolation. The opponents of these scripts have not come up with an alternative that covers why people are using them. As for zc.buildout, I took a very brief look at the webpage, saw a config file or two, and realized it's quite more complex than I want to deal with right now -- if it even does this job. But I released a Python library recently, and pondered whether to use the "modern" setuptools or the "universal" distutils. I opted for distutils because I didn't need any setuptools-specific functionality. No doubt other programmers have the same dilemma: switch to setuptools now or wait? The critical thing is, Python has already reached the point where people have to use unofficial and not-centrally-documented tools to build and release packages, and this is not a good thing. Setuptools, workingenv, and virtual-python -- or their successors -- need to be integrated into Python. As to whether Python is delving into areas belonging to package managers, Perl has had CPAN for over a decade and it's widely acclaimed, and people chided Python for years for not having something equivalent. -- Mike Orr <[EMAIL PROTECTED]> --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
