easy_install: --tag-svn-revision
Should easy_install have a --tag-svn-revision option like setuptools/setup.py has? I'm feeling a desire for it now, while installing someone else's package that's only available in svn. -- Ian Bicking / ianb@colorstudy.com / http://blog.ianbicking.org
At 11:12 AM 8/10/2005 -0500, Ian Bicking wrote:
Should easy_install have a --tag-svn-revision option like setuptools/setup.py has? I'm feeling a desire for it now, while installing someone else's package that's only available in svn.
One minor concern: should --tag-svn-revision apply to dependencies too? I'm -0 on this, since --editable lets you do this with only a little fuss. If you can come up with a rationale for dealing with dependencies or multiple easy_install targets, and a patch, I'll take it.
Phillip J. Eby wrote:
At 11:12 AM 8/10/2005 -0500, Ian Bicking wrote:
Should easy_install have a --tag-svn-revision option like setuptools/setup.py has? I'm feeling a desire for it now, while installing someone else's package that's only available in svn.
One minor concern: should --tag-svn-revision apply to dependencies too?
I'm -0 on this, since --editable lets you do this with only a little fuss. If you can come up with a rationale for dealing with dependencies or multiple easy_install targets, and a patch, I'll take it.
I want to install a package that isn't using setuptools, so I can't run "setup.py develop" without changing the setup.py file to use setuptools. I don't think --tag-svn-revision should apply to dependencies. Maybe it should even be an error if you try to use it on a package that isn't a subversion repository. Really the reason I brought it up is that easy_install can apply setuptools commands to non-setuptools distributions, but "setup.py develop" can't. -- Ian Bicking / ianb@colorstudy.com / http://blog.ianbicking.org
At 03:08 PM 8/10/2005 -0500, Ian Bicking wrote:
I don't think --tag-svn-revision should apply to dependencies. Maybe it should even be an error if you try to use it on a package that isn't a subversion repository.
On the other hand, I don't suppose it would hurt to just ignore it if it doesn't apply. I'm uneasy about dependencies, of course, but then again, where's the harm there either? The biggest potential harm of --tag-svn-revision is that it makes things a *higher* revision number by default. I.e. "1.2-r27" is a higher version number than "1.2", so if you're using a strategy where you use the *next* version number in your svn version of setup.py, then you're going to have problems when the official version is released. In other words, if svn's setup.py says "1.2" is the current version, but that's the version you're *developing* (as opposed to enhancing), then the numbering works out wrong.
Phillip J. Eby wrote:
At 03:08 PM 8/10/2005 -0500, Ian Bicking wrote:
I don't think --tag-svn-revision should apply to dependencies. Maybe it should even be an error if you try to use it on a package that isn't a subversion repository.
On the other hand, I don't suppose it would hurt to just ignore it if it doesn't apply. I'm uneasy about dependencies, of course, but then again, where's the harm there either?
The harm in adding the revision there? Not that great, I guess. It's kind of a stop-gap measure either way; modifying setup.cfg in the repository itself seems like the right way to handle the versions.
The biggest potential harm of --tag-svn-revision is that it makes things a *higher* revision number by default. I.e. "1.2-r27" is a higher version number than "1.2", so if you're using a strategy where you use the *next* version number in your svn version of setup.py, then you're going to have problems when the official version is released. In other words, if svn's setup.py says "1.2" is the current version, but that's the version you're *developing* (as opposed to enhancing), then the numbering works out wrong.
True. I'm never sure what version I should use in a repository. The next version isn't true, the last version isn't true. "next_version-DEV" is probably right, I guess. Nevertheless, it's still possible to use --tag-build to fix version numbers in case of problems. It's not very sticky, though; it'd be easy to forget how it should be properly applied, or how it was applied in the past. The ability to list packages would help resolve what problems do occur; especially listed in the order pkg_resources thinks they go in, showing which one is active, etc. The main reason for stuff like this is to make it possible to use easy_install.py for an entire deployment without requiring all the software to be written with setuptools in mind. So even if it is suboptimal, it's still of some use. Another option might be something like "python -m setuptools setup.py" which would run setup.py with setuptools. But then this is really just what easy_install does, except with a larger command set (egg_info in particular). "easy_install.py --setup checkout-dir/ setuptools_commands..." perhaps? -- Ian Bicking / ianb@colorstudy.com / http://blog.ianbicking.org
At 05:23 PM 8/10/2005 -0500, Ian Bicking wrote:
Phillip J. Eby wrote:
At 03:08 PM 8/10/2005 -0500, Ian Bicking wrote:
I don't think --tag-svn-revision should apply to dependencies. Maybe it should even be an error if you try to use it on a package that isn't a subversion repository.
On the other hand, I don't suppose it would hurt to just ignore it if it doesn't apply. I'm uneasy about dependencies, of course, but then again, where's the harm there either?
The harm in adding the revision there? Not that great, I guess. It's kind of a stop-gap measure either way; modifying setup.cfg in the repository itself seems like the right way to handle the versions.
The biggest potential harm of --tag-svn-revision is that it makes things a *higher* revision number by default. I.e. "1.2-r27" is a higher version number than "1.2", so if you're using a strategy where you use the *next* version number in your svn version of setup.py, then you're going to have problems when the official version is released. In other words, if svn's setup.py says "1.2" is the current version, but that's the version you're *developing* (as opposed to enhancing), then the numbering works out wrong.
True. I'm never sure what version I should use in a repository. The next version isn't true, the last version isn't true. "next_version-DEV" is probably right, I guess.
Not quite; the '-' means that 'DEV' is a patchlevel, and goes right back to the "later version" problem. You need something like '1.2dev' or '1.2pre' to make it a pre-release version.
Nevertheless, it's still possible to use --tag-build to fix version numbers in case of problems. It's not very sticky, though; it'd be easy to forget how it should be properly applied, or how it was applied in the past.
Personally, I create aliases for different build patterns, and just run those aliases. "setup.py alias" is your friend. :)
Another option might be something like "python -m setuptools setup.py" which would run setup.py with setuptools. But then this is really just what easy_install does, except with a larger command set (egg_info in particular). "easy_install.py --setup checkout-dir/ setuptools_commands..." perhaps?
Try Ryan's buildutils (just "easy_install buildutils"). His 'pbu' script runs setup.py with setuptools installed, and as of the CVS version, setuptools now embeds itself deep into the distutils so that even a script that doesn't use setuptools should end up using setuptools anyway, at least enough to enable the full command set. Whether that *actually* works with the current versions of buildutils and setuptools, I couldn't say. I don't know if buildutils has been updated to work with the entry point stuff for distutils extensions yet, although even if it hasn't it might still work anyway.
participants (2)
-
Ian Bicking -
Phillip J. Eby