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
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
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>
_______________________________________________
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.
...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
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
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
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
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
