On Thu, Jun 11, 2009 at 9:03 AM, Ian Bicking<[email protected]> wrote: > On Thu, Jun 11, 2009 at 10:53 AM, P.J. Eby<[email protected]> wrote: >> For example, if I'm working on two projects that are distributed via SVN and >> one depends on the other, if I update one, it may require an update of the >> other; the failure of the .dev#### version requirement in the first one will >> inform me of the need to "svn up" the second project and rerun "setup.py >> develop" on it. >> >> This is a routine circumstance in at least my development cycle; I would >> expect that it's the case in other open source development workflows as well >> as proprietary ones. > > Agreed, I do this all the time. Pylons dev versions also regularly > rely on other packages with a dev version, and people regularly use > these non-released versions, with dependencies detected and installed > via dependency_links.
If there were a setup.py metadata field (called "dev_revision" or "build_number" or something), separate from the "version" field, that was used to hold the value for sorting/distinguishing unreleased versions... could that work? I.e. Have the shorter "N.N.N[(a|b|c)N]" scheme for "version" to be used for "released" packages. And have a separate field (or fields) for use in dependency handling of unreleased versions? Putting the two together is resulting in package uploads to PyPI (foo-1.2.3.dev-r456.tar.gz) that I think were never intended in the design A weird thing about defining a sort order for: 1.2.3.dev-r450 1.2.3 # this is the released version (svn rev was r454) 1.2.3-r456 is that it is comparing apples and oranges. The "1.2.3" released version *had* a VCS revision number (or release date, or "number of patches"). Trent -- Trent Mick [email protected] _______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
