Mailman 3 May 2009 - Distutils-SIG

Re: [Distutils] RFC : Version comparison
by P.J. Eby May 14, 2009

May 14, 2009

At 10:59 AM 5/14/2009 +0200, Tarek Ziadé wrote: >2009/5/14 P.J. Eby <pje(a)telecommunity.com>: > > At 02:34 PM 5/13/2009 +0200, Tarek Ziadé wrote: > >> > >> Any feedback on this "dev version of post release" use case > > > > It looks like the 'suggest' function doesn't handle svn revisions properly > > for conversion from setuptools versions. Setuptools '-r###' is a > > post-release tag, as is any alpha string alphabetically after > 'final'. That > > is, '0.4a1.r10' is actually '0.4a1.post10'. (Notice, for example, that > > setuptools' trunk version is '0.7a1dev-r66608'.) > > > > See > > > http://peak.telecommunity.com/DevCenter/setuptools#specifying-your-project-… > > for the full syntax; I'm a bit concerned that there may be other incorrect > > interpretations taking place in this function. (Notice, for > example, that a > > '-' in a version number indicates a post-release, but your code is treating > > '-' as identical to '.'.) > >Ok, I have changed the suggest function accordingly, > > > def test_suggest_rational_version(self): > > self.assertEquals(suggest('1.0'), '1.0') > self.assertEquals(suggest('1.0-alpha1'), '1.0a1') > self.assertEquals(suggest('1.0rc2'), '1.0c2') > self.assertEquals(suggest('walla walla washington'), None) > > # from setuptools > self.assertEquals(suggest('0.4a1.r10'), '0.4a1.post10') > self.assertEquals(suggest('0.7a1dev-r66608'), '0.7a1.dev66608') > self.assertEquals(suggest('0.6a9.dev-r41475'), '0.6a9.dev41475') > self.assertEquals(suggest('2.4preview1'), '2.4c1') > self.assertEquals(suggest('2.4rc1'), '2.4c1') > self.assertEquals(suggest('2.4pre1') , '2.4c1') All looking pretty good, except: > self.assertEquals(suggest('2.1-rc2'), None) # no suggestion This should be equivalent to '2.1c2': >>> from pkg_resources import parse_version as pv >>> pv('2.1-rc2')==pv('2.1c2') True

1 0

PEP 376 - site-directories and site.addsitedir
by Tarek Ziadé May 14, 2009

May 14, 2009

Hello for PEP 376, I have one last fuzzy point. http://svn.python.org/view/peps/trunk/pep-0376.txt?view=markup The "get_egg_info" api is currently based on scanning the whole sys.path. And since sys.path can be modified by people, so the algorithm is linear and can slow down when there are a lot of paths. I have a proposal: let's restrict the search for this API to site-package directories only. (directories added with site.addsitedir) People will be able to mark add any directory (like the per-user site-package directory - http://www.python.org/dev/peps/pep-0370) This requires to add in site.py a registry to keep track of all directories added through site.addsitedir Any thoughts ? (In the meantime, I'll propose the inclusion of a sitedir list in site, in Python-ideas) ++ Tarek -- Tarek Ziadé | http://ziade.org

2 1

[issue69] No 2.6 install setup
by mkesper May 14, 2009

May 14, 2009

New submission from mkesper <mkesper(a)schokokeks.org>: If you want to install 0.6c9 on windows, you face a hen-and-egg-Problem: An .eeg exists, but no installer. ---------- messages: 287 nosy: mkesper priority: feature status: unread title: No 2.6 install setup _______________________________________________ Setuptools tracker <setuptools(a)bugs.python.org> <http://bugs.python.org/setuptools/issue69> _______________________________________________

1 0

Re: [Distutils] RFC : Version comparison
by P.J. Eby May 14, 2009

May 14, 2009

At 02:34 PM 5/13/2009 +0200, Tarek Ziadé wrote: >Any feedback on this "dev version of post release" use case It looks like the 'suggest' function doesn't handle svn revisions properly for conversion from setuptools versions. Setuptools '-r###' is a post-release tag, as is any alpha string alphabetically after 'final'. That is, '0.4a1.r10' is actually '0.4a1.post10'. (Notice, for example, that setuptools' trunk version is '0.7a1dev-r66608'.) See http://peak.telecommunity.com/DevCenter/setuptools#specifying-your-project-… for the full syntax; I'm a bit concerned that there may be other incorrect interpretations taking place in this function. (Notice, for example, that a '-' in a version number indicates a post-release, but your code is treating '-' as identical to '.'.) >or I move >forward and integrate it ? Into the stdlib? I'm a bit surprised that something with such global consequences is having its bleeding edge development done in the stdlib, rather than as an external package. I sort of assumed at first the idea was to provide a normalized or canonical form for setuptools versions, but of course it's a bit more restrictive than that, and at the moment the only mapping between the two seems broken -- and in a way that suggests the designers neither read the setuptools version documentation nor examined what people were actually doing with their versioning schemes. To be clear, I'm not opposed to blessing a normalized version scheme -- there are solid benefits to doing such a thing. I'm opposed to putting one in the stdlib without a clear rationale for the choices, and an upgrade path that either lets setuptools users ignore the new scheme, or gives them some benefit for switching. Meanwhile, I haven't seen any indication that this new format is easier for non-Python tools to parse. Is the plan for other tools to use the stdlib parsing code, because I don't see how existing tools like RPM et al could use the proposed scheme.

2 2

Eggs, zc.buildout, and Distributed Version Control, oh my!
by Ross Patterson May 14, 2009

May 14, 2009

...and of course the elephant in the living room, svn:externals. :) I've been using DVC (git mostly) more and more these days and enjoying it very much. It works particularly well when I have a self-contained software package. I tend to start a project in SVN with the standard trunk/branches/tags layout and then use git in front of the SVN repo. I make the egg root itself a buildout for a test environment with my favorite but not required development tools. (Of course I test with "python setup.py test" before release when the egg doesn't require any additional deployment details provided by the buildout. I don't want to get into that discussion.) It all works much better than trying to work directly with SVN far beyond the benefits of just being able to work offline. What I want to ask about and still haven't worked out an answer to is how to best manage framework or deployment projects where I am developing a number of eggs in parallel under a buildout that needs to be versioned as well. In this case, I'm finding moving away from svn:externals more painful than I expected. Having an overview of all version control status for all code being developed is very valuable. Now some of this comes down to eggs being overused and I've certainly been guilty of that myself. For example, I used to make separate eggs for all my client specific code (policy, theme, etc.). This is clearly unnecessary and I've switched to using one egg that contians multiple sub-packages for factoring. Even with that, however, I still find the lack of a good "what changes have I made to all sub projects" overview to be rather painful. Maybe this is outside the scope of the individual DVC tool and should be handled by an independent tool that aggregates status across projects. How do others handle this kind of situation? Ross

2 2

Re: [Distutils] RFC : Version comparison
by P.J. Eby May 13, 2009

May 13, 2009

At 08:58 PM 5/6/2009 +0200, Tarek Ziadé wrote: >Sorry to post again that mail, but it seems that this is the last remaining >issue for the versionning proposal. > >Phillip, could you check my proposal for your development versions of >postreleases >use case ? Is the code up-to-date with the below? >thx > >On Thu, Apr 23, 2009 at 11:19 AM, Tarek Ziadé <ziade.tarek(a)gmail.com> wrote: > > 2009/4/22 P.J. Eby <pje(a)telecommunity.com>: > >> I don't see how it can manage, e.g. a development version of a > postrelease, > >> with an SVN rev or date stamp on it. Such versions might not be found on > >> PyPI or on RPMs, but would be needed in development. > > > > So, instead of having 'dev' and 'post', we would require a third case > > for "pos+dev" version > > > > so (dev|post)N+ could become, ((dev|post)N+)|(postN+devN+) > > > > example: > > > > 1.0.dev459 < 1.0 < 1.0.post456dev463 < 1.0.post456 < 1.0.post489 > > > > > >> > >> (Btw, the wiki page pseudo-regex doesn't match what the code actually > >> parses, either.) > >> > > > > i'll check it thx > > > >> > > > > > > > > -- > > Tarek Ziadé | http://ziade.org > > > > > >-- >Tarek Ziadé | http://ziade.org

2 3

Distutils roadmap : 8th may
by Tarek Ziadé May 13, 2009

May 13, 2009

Hello, I would like to make some decisions and move forward on three topics for Distutils : 1/ version comparison : http://wiki.python.org/moin/Distutils/VersionComparison 2/ standardization of egg-info : PEP 376 + http://wiki.python.org/moin/Distutils/StandardizeEggInfo 3/ changes in PKG-INFO : PEP 345 + http://svn.python.org/projects/peps/branches/jim-update-345/pep-0345.txt + http://wiki.python.org/moin/Distutils/Metadata I propose to settle on these three topics and set next friday (8th may) as a deadline. Cheers Tarek -- Tarek Ziadé | http://ziade.org

2 1

Buildout: adding a download API?
by Thomas Lotze May 12, 2009

May 12, 2009

Buildout as well as a number of buildout recipes need to download files from the net. They need to take care of doing the actual download, using the download cache and honouring the offline option. A couple of years ago, we also wrote the gocept.download recipe that does all that as well as MD5 checks and some other stuff. In order to simplify this situatin, we propose adding a download API to buildout itself. A function like this: def download(url, use_cache=True, md5sum=None) ... return filename might be sufficient to remove the download logic from recipes and make optional checksum testing available without needing to depend on a separate download recipe. As a consequence, zc.recipe.cmmi would be able to do MD5 checks, which would basically make gocept.cmmi redundant. Using gocept.download's capabilities is the one feature of it which still currently keeps us from dropping it in favour of zc.recipe.cmmi. If there's no objection against a download API being added to buildout, we'd like to implement one soon. Otherwise, we'd propose implementing MD5 testing in zc.recipe.cmmi since we consider it a good thing to reduce the zoo of cmmi-related recipes. We do think that a reusable API would be the better choice, though. Viele Grüße, Thomas -- Thomas Lotze · tl(a)gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development

2 1

Setuptools release (svn 1.6)
by Tarek Ziadé May 12, 2009

May 12, 2009

Phillip, What about blessing someone to review and commit the patch for svn 1.6 support (and maybe other patches) and do a setuptools release ? Regards Tarek -- Tarek Ziadé | http://ziade.org

2 1

Possible bug in setuptools - test command?
by Iwan Vosloo May 11, 2009

May 11, 2009

Hi there, We've been having some trouble with a script which invokes setuptools.setup(script_args=['test']) more than once in a single process. During each invocation, python imports different, new instances of the same module. We've narrowed it down to setuptools/command/test.py, in the method with_project_on_sys_path: It saves sys.modules like this: old_modules = sys.modules.copy() Then does its thing and restores sys.modules like this: sys.modules.clear() sys.modules.update(old_modules) But, as the code below illustrates, this results in multiple imports of the same modules: import sys def i(): old_modules = sys.modules.copy() from decimal import Decimal sys.modules.clear() sys.modules.update(old_modules) return Decimal assert i() is i(), 'Two different Decimal instances returned' # Fails Is this a bug? (We are on version 0.6c8 of setuptools, python 2.5) There is an easy solution: Save sys.modules like before: old_modules = sys.modules.copy() But restore it like this: sys.modules = old_modules That seems to fix our problem (not sure of other effects though). Regards - Iwan Vosloo

1 1