Hello all,
I discovered the joys of the --user option: no more need for
PYTHONPATH in many cases, simply run
python setup.py install --user
And I wonder if it would be possible to add this functionality/option
to the develop command too?
Thanks !
___
On Thu, 4 Jun 2009 16:15:11 +0200, Tarek Ziadé
wrote:
> I think that would be great to externalize such command to decouple
> its release cycles from Python (As mentioned during the Langage summit)
>
> The only requirement would be to find someone that would lead its
> development,
>
> If I find
Gerry Reno wrote:
Tarek,
Speaking of packaging patches. Would there be any chance that you
could get the 'bdist_deb' patches integrated in Distutils prior to PyCon?
Hi Tarek,
Has there been any progress on getting the 'bdist_deb' target (akin to
'bdist_rpm') implemented in Distutils? We are
2009/6/5 Tarek Ziadé :
> At least I hope we all agree that : 2009.05.12 is not a good version number,
> and that we all want a major/minor scheme.
Well, Twisted and Ubuntu might both disagree :-) But it's no more of a
problem than 1.7.5 - the numbers are just a bit bigger, and there are
gaps.
Fra
On Fri, Jun 5, 2009 at 4:59 PM, Paul Moore wrote:
> 2009/6/5 Tarek Ziadé :
>> No one will force people to use the one we are defining, like no one
>> forced people
>> to use StrictVersion or LooseVersion.
>
> But it's being defined via a PEP (rather than hidden in the code, as
> with Strict/LooseVs
At 03:13 PM 6/5/2009 +0200, Tarek Ziadé wrote:
But so far, besides that very specific case for the post-release dev
tag, I don't find
it complicated at all.
...and I'm a little bit concerned that perhaps there was some
confusion about that use case and maybe something got more
complicated tha
2009/6/5 Tarek Ziadé :
> No one will force people to use the one we are defining, like no one
> forced people
> to use StrictVersion or LooseVersion.
But it's being defined via a PEP (rather than hidden in the code, as
with Strict/LooseVsersion) so it has a higher level of visibility and
authorita
On Fri, Jun 5, 2009 at 4:20 PM, Ben Finney wrote:
>> We worked during two evenings during Pycon with people from Fedora and
>> Ubuntu on that (Toshio and Matthias Klose). Those people are packaging
>> Python projects for their systems and have problems because of the
>> lack of proper versioning so
Brandon Craig Rhodes writes:
> With a caveat (or maybe this is the way it already works?) that every
> series of adjacent digits in the version be compared as an integer
> occupying a single character's worth of string, regardless of how many
> digits compose the integer
Right. This is what I me
Tarek Ziadé writes:
> On Fri, Jun 5, 2009 at 3:55 PM, Ben Finney wrote:
> > Tarek Ziadé writes:
> >
> >> There's a consensus on this in most packaging system out there, and
> >> the goal is to have a rational version system that is understandable
> >> by most packagers so they can work with pyth
Ben Finney writes:
> Those that do specify are *much* more obvious and simple in their
> comparison of individual components than what is currently in the
> ‘distutilsversion’ specification. Usually it's a simple case of “once
> we've got the individual components of a version string, they compar
On Fri, Jun 5, 2009 at 3:55 PM, Ben Finney wrote:
> Tarek Ziadé writes:
>
>> There's a consensus on this in most packaging system out there, and
>> the goal is to have a rational version system that is understandable
>> by most packagers so they can work with python projects versions.
>
> Have you
Ben Finney writes:
> >>> from verlib import RationalVersion as V
> >>> (V('1.0')
> ... < V('1.0.a1')
> ... < V('1.0.a2')
> ... < V('1.0.a2.1')
> ... < V('1.0.b2')
> ... < V('1.0.c1')
> ... < V('1.0.dev456post623')
> ... < V('1.0.post456'))
> True
+1
Tarek Ziadé writes:
> There's a consensus on this in most packaging system out there, and
> the goal is to have a rational version system that is understandable
> by most packagers so they can work with python projects versions.
Have you actually read the version comparison specifications of oth
Tarek Ziadé writes:
> On Fri, Jun 5, 2009 at 2:43 PM, Paul Moore wrote:
> > I'd rather the PEP said "This is how version numbers work (simple,
> > non-controversial spec here), and this is the standard API for
> > manipulating them", and then projects that want to conform to the
> > standard migr
2009/6/5 Tarek Ziadé :
>> But I acknowledge that I have no personal requirement for any of this,
>> so the only interest I have is an aesthetic one of *not* seeing
>> overcomplicated, difficult to understand, specifications become part
>> of the Python stdlib.
>
> Well if the specification is diffi
On Fri, Jun 5, 2009 at 2:43 PM, Paul Moore wrote:
> I'd rather the PEP said "This is how version numbers work (simple,
> non-controversial spec here), and this is the standard API for
> manipulating them", and then projects that want to conform to the
> standard migrate if needed.
That's exactly t
On Fri, Jun 5, 2009 at 11:19 AM, Ben Finney wrote:
>
> Yet the discussion around these non-obvious semantics, trying to have
> components interpreted as “pre-release” and “post-release” and
> “development release” and so on seem to underline the fact that
> they're *not* something that there's any
2009/6/5 Ben Finney :
> Tarek Ziadé writes:
>
>> http://bitbucket.org/tarek/distutilsversion/src/tip/README.txt
>>
>> The goal here is to provide a version comparison standard to be
>> included in Distutils.
>
> I laud this goal, and thank you for soliciting feedback on this draft.
>
> One thing
Tarek Ziadé writes:
> http://bitbucket.org/tarek/distutilsversion/src/tip/README.txt
>
> The goal here is to provide a version comparison standard to be
> included in Distutils.
I laud this goal, and thank you for soliciting feedback on this draft.
One thing I haven't seen discussed: Why hav
Tarek Ziadé wrote:
>
> The idea of the uninstall API is to provide a reference implementation
> that can be used
> in package managers that will rely on the other APIs, rather than a
> complete system.
>
For package managers which manage everything (pretty much every native
binary installer, be
21 matches
Mail list logo
