I'm thinking about making a slight change to this for the actual implementation
in 0.7a1. Instead of specifying the VCS via the command line, I'm thinking
about specifying a VCS plugin via a setup() keyword, e.g.
"vcs_plugin='setuptools_hg'" to request the use of a specific plugin, with the
default being equivalent to 'setuptools'. This would control both revision
tagging and file finders, and be equivalent to a conditional 'setup_requires'
when building an sdist. Heck, it might even help with making sure that
SOURCES.txt is correct/clean.
One additional advantage to this is that --tag-svn-revision can become an alias
for a --tag-revision command that just asks the specified VCS plugin for a
revision. But the flip side is that you can't override *which* plugin is used
without editing setup.py. Seems reasonable enough to me, but maybe somebody has
another use case?
All right, here's the update.
I reverted to --revision-tagger, but put the SVN code in egg_info.py
Also, I added support for tagger options: the code only looks at the part of
revision_tagger before the first colon, then passes the whole thing to the
tagger function. This should be helpful for some plugins.
Hm. I hadn't thought of the pathological case. I suppose it would
be helpful to have the option to force it in that situation. I guess
that makes sense.
Ok, you talked me into it! Keep the options the way you had
them. And the module-level function is okay.
Okay, I'll change that.
There are times when I have a tree managed by both Bazaar and SVN, because
Bazaar lets me save local commits but the upstream uses SVN, but I guess that's
a pathological case.
Hmm. I'm not sure how to do option aliases (for instance if I see both
--tag-revision and --no-tag-svn-revision, how do I know which came from the
command line and should override the other?). It seems fancy_getopt supports
positive aliases, but there's no way to specify them from a Command.
Am I missing something? (If not, the generic options should probably just
override the -svn- variants.)
(Keeping the SVN tagging inside egg_info.py, but making it a module-level
function is OK?)
I'll post another patch when this is sorted out, there's a Bazaar branch at
https://code.launchpad.net/~encukou/setuptools/revision-tagger for the time being.
Definitely getting closer. Specifying a plugin is unnecessary,
however. It should just loop over installed plugins and ask if they
know the revision, termininating on the first one returning a
non-None value. And I'd prefer to see '--tag-revision' and
'--no-tag-revision' options that are essentially aliases to the
existing SVN-specific options. (There's also no need to move the SVN
tagging to a different module.)
Included is a patch that creates a "setuptools.revision_taggers" entrypoint,
which allows plugins to provide revision tags, and a "revision_tagger" option to
egg_info, which allows users to choose such a tagger.
I made the tagger function return the whole tag, including -r, because
distributed VCSs will probably need more than just a number to keep revisions at
least close to monotonic.
1. Please make this backward-compatible; it can't simply throw out
--tag-svn-revision or drop the core support for SVN and CVS. Even if it's
0.7-only, it will still have to be able to handle the setup.cfg of existing
2. get_filters() should return a list of callables, not strings, and it
shouldn't be called from the inner function: it should be called once from the
outer function and the result saved. As written, this is a horrible
inefficiency, as it will be searching for entry points for every single file in
the egg-info. (Also, a straight-string filter with no programmability won't
work for every revision control system.)
3. The error trapping around the file finder loop is bogus. The entry point
itself must handle any errors.
4. The patch shouldn't be changing setuptools' version number, or adding entry
points referencing modules that aren't even included in the patch.
5. The exclude_pattern() stuff is treating arbitrary filter strings as regexes
but isn't escaping them. Of course, it should be using filter functions anyway,
but I thought I should mention that what's there is broken irrespective of this.
This is a basic try (4h) to extract specific SVN code out of the core
and add entry points for:
- filters (.svn, .hg, ...)
- find files in repos
- get revision's number
- if repos have 2 VCS entries (.svn and .hg for example), the first
valid entry point is used.
- walk_revctrl function needs more love. I keep the philosophy of
iterator but is it the good way ?
- vcs_svn.py & vcs_hg.py are only for demo. The natural place are into
- filters must return a list.
- revisions must return a int or None (not 0).