Jeff Rush wrote: > Dave Peterson wrote: >> >> I agree. Let's get that setuptools wiki started and start >> documenting some of these ideas as a roadmap so that anyone who wants >> to help out has an idea of what to work on, or factor into what >> they're currently working on. > >> Anyway, since Enthought is already scratching, I'm fine with the idea >> of building a standard way to do it that is driven by human-readable >> data. We just need to setup the process to allow that to happen. >> So far I haven't seen any responses from you in regards to the setup >> of an issue/patch tracker, wiki, process to open up the number of >> commiters, etc. that gives me any confidence I'm not heading off down >> the wrong path somehow. Perhaps I'm too cautious? > > Dave, I'm in the process of getting a tracker for setuptools, and I'll > work on the wiki shortly, although we have the PackagingBOF wiki for > idea collection at the moment. Give me a couple of days, including > travel from PyCon. I'm fired up to make this happen.
Awesome. Travis O came back into the office from being at PyCon today and I've finally got the full set of e-mail addys from the people who attended the PackagingBOF meetings. I'd like to e-mail everyone with info about the tracker and wiki, and possibly a new dev type mailing list seeded with these names. Anything I can send out now? :-) >>> Actually, I wonder if instead of trying to enhance setuptools for >>> post-install, if maybe we should be looking at buildout recipes and >>> maybe having a way for setuptools dependencies to point to buildout >>> specs. IIRC, buildout specs can be remotely retrieved from a single >>> URL, too. >> >> I'll need to read up more on buildout to understand this, but my >> understanding was that buildout was not something a user ran to >> install an app, but rather something the developer ran to build and >> publish an app. The end result of a 'production' buildout is to >> generate a large tarball or rpm that included everything, right? If >> so, this goes directly against what Enthought was aiming for, which >> was to allow delivery of bug-fixes and minor updates in a large app >> by downloading only smaller units instead of a huge monolithic >> re-install of everything. > > Your view of a fine-grained application bundle with the ability to > dynamically download updated eggs without re-pulling the entire thing > is an interesting contrast to Paul's view of a more monolithic > application for easier add/remove/uninstall completeness. Supporting > both usage models is going to be a challenge but I think is feasible > with some thought. Yes, that will be interesting indeed. I'm not sure we need anything more to support what we'd like to do than to resolve some dependency lookup issues that I've already talked about on this list and at the PackagingBOF. -- Dave > > -Jeff > _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
