2009/6/4 P.J. Eby :
> In setuptools' case, the original intent was to be compatible with projects
> that do have things like '2.4-1' - e.g., because they're a wrapper of a
> library whose version is 2.4, and the wrapper is the first version of that.
> If the library then releases a '2.4.1', the wr
At 10:44 AM 6/4/2009 -0700, Trent Mick wrote:
Back to a "dev version of a post release", given the only examples I've seen:
- "2.4-r1263": given that the post-release is using the Subversion
revision number here, how can a "dev version" if this be meaningful?
- "2.4-20051127": A potential alterna
On Thu, Jun 04, 2009 at 12:46:03PM -0400, P.J. Eby wrote:
> At 12:57 PM 6/4/2009 +0200, Tarek Ziadé wrote:
>> On Thu, Jun 4, 2009 at 11:52 AM, Brian Sutherland
>> wrote:
>> > I can imagine distutils uninstalling files previously installed by dpkg
>> > as a shortcut to breaking a machine. Though I'
2009/6/4 P.J. Eby
>
> At 09:41 AM 6/4/2009 -0700, Trent Mick wrote:
>>
>> Can people point to some examples of projects using post-release tags, and
>> that would require the use of a "dev release of a post release"?
>
> Any project that uses a post-release tag and has multiple developers or
> m
2009/6/4 P.J. Eby
>
> The specific use case I was asking about, though, was "1.0a1dev-r623",
> meaning "SVN revision 623 of the development work on leading up to 1.0a1" --
> and IIRC, in the RationalVersion cheme, this should probably just translate
> to "1.0.a1.dev623".
>
That is correct.
Tren
At 09:41 AM 6/4/2009 -0700, Trent Mick wrote:
Can people point to some examples of projects using post-release
tags, and that would require the use of a "dev release of a post release"?
Any project that uses a post-release tag and has multiple developers
or multiple commits required to create
At 03:02 PM 6/4/2009 +0200, Tarek Ziadé wrote:
On Thu, Jun 4, 2009 at 2:26 PM, Floris Bruynooghe
wrote:
>>
>> This is a dev version of a post-release version. Which is an edge case
>> submitted by Phillip.
>>
>> How would you write it ?
>
> 1.0.post623dev456 is what feels intuitive to me, here's
At 01:23 PM 6/4/2009 +0100, Paul Moore wrote:
With Windows, if you install using bdist_wininst and then uninstall
using the (currently nonexistent) distutils uninstall, I'd expect that
it wouldn't remove the Add/Remove programs support items in the
registry, and the Removexxx.exe and xxx-wininst.
2009/6/4 P.J. Eby
> At 11:17 AM 6/4/2009 +0200, Tarek Ziadé wrote:
>
>> - new PEP 386 | waiting for your feedback
>>
>> - http://svn.python.org/projects/peps/trunk/pep-0386.txt
>>
>
>
> From the PEP:
>
>> Last ".dev456post623" is a development version of a post-release
>>
>
> This appears incorr
At 12:57 PM 6/4/2009 +0200, Tarek Ziadé wrote:
On Thu, Jun 4, 2009 at 11:52 AM, Brian Sutherland
wrote:
> I can imagine distutils uninstalling files previously installed by dpkg
> as a shortcut to breaking a machine. Though I'm not sure what will
> actually happen in practice.
Distutils defines
On Thu, Jun 4, 2009 at 6:02 AM, Tarek Ziadé wrote:
> On Thu, Jun 4, 2009 at 2:26 PM, Floris Bruynooghe
> wrote:
> >>
> >> This is a dev version of a post-release version. Which is an edge case
> >> submitted by Phillip.
> >>
> >> How would you write it ?
> >
> > 1.0.post623dev456 is what feels i
At 11:17 AM 6/4/2009 +0200, Tarek Ziadé wrote:
- new PEP 386 | waiting for your feedback
- http://svn.python.org/projects/peps/trunk/pep-0386.txt
From the PEP:
Last ".dev456post623" is a development version of a post-release
This appears incorrect to me; it should be a post-release of a
2009/6/4 David Cournapeau :
> Brian Sutherland wrote:
>> Yep. Though I think that nowdays dpkg installs to a different directory than
>> Distutils' default. So users have to specify extra options to break
>> their systems.
>>
>
> That's unfortunately not true: by default (wo any --prefix option),
>
2009/6/4 Tarek Ziadé :
> On Thu, Jun 4, 2009 at 3:59 PM, Paul Moore wrote:
>>
>> Also, you need to remember that bdist_wininst is not a "third-party"
>> tool. It's part of distutils (although it's probably written in such a
>> way that it could easily be extracted as a 3rd party addin - I
>> hones
On Thu, Jun 4, 2009 at 3:59 PM, Paul Moore wrote:
>
> Also, you need to remember that bdist_wininst is not a "third-party"
> tool. It's part of distutils (although it's probably written in such a
> way that it could easily be extracted as a 3rd party addin - I
> honestly don't know).
I think that
2009/6/4 Tarek Ziadé :
> Paul
>> I'd say that it's distutils' responsibility not to offer to uninstall
>> anything it didn't install.
>
> Brian
>> Yep. Though I think that nowdays dpkg installs to a different directory than
>> Distutils' default. So users have to specify extra options to break
>> t
2009/6/4 Tarek Ziadé :
> On Thu, Jun 4, 2009 at 3:41 PM, Brian Sutherland
> wrote:
>>> And easy_install would have its own marker maybe, if the way it
>>> installs stuff slighlty differs
>>
>> ok, seems reasonable:)
>
> I'll work on that. I guess it's time to code the uninstall prototype,
>
>>
>>
On Thu, Jun 04, 2009 at 01:23:21PM +0100, Paul Moore wrote:
> 2009/6/4 Tarek Ziadé :
> >>> - PEP 376 | status : waiting for Phillip complementary feedback (and
> >>> anyone else of course)
> >>
> >>
> >> I can imagine distutils uninstalling files previously installed by dpkg
> >> as a shortcut to b
On Thu, Jun 4, 2009 at 3:41 PM, Brian Sutherland
wrote:
>> And easy_install would have its own marker maybe, if the way it
>> installs stuff slighlty differs
>
> ok, seems reasonable:)
I'll work on that. I guess it's time to code the uninstall prototype,
>
> Perhaps the --installer option take a
2009/6/4 Tarek Ziadé :
> On Thu, Jun 4, 2009 at 3:23 PM, Brian Sutherland
> wrote:
>>
>> So, with setuptools I was running this while building a package:
>>
>> python2.X setup,py install --single-version-externally-managed
>> --root=debian/$(package) --install-data=usr/lib/$(package)
>>
>> So,
On Thu, Jun 4, 2009 at 3:29 PM, Tarek Ziadé wrote:
> On Thu, Jun 4, 2009 at 3:23 PM, Brian Sutherland
> wrote:
>>
>> So, with setuptools I was running this while building a package:
>>
>> python2.X setup,py install --single-version-externally-managed
>> --root=debian/$(package) --install-data=
On Thu, Jun 4, 2009 at 3:23 PM, Brian Sutherland
wrote:
>
> So, with setuptools I was running this while building a package:
>
> python2.X setup,py install --single-version-externally-managed
> --root=debian/$(package) --install-data=usr/lib/$(package)
>
> So, now I would need to run this:
>
>
2009/6/4 David Cournapeau :
> Ideally, distutils should detect whether it installed the package itself
> or not.
Yes, I think having a marker like I suggested some minutes ago, would help
>
> IMHO, uninstall is beyond the scope of distutils; it is very difficult
> to get right, with so many ways
2009/6/4 Tarek Ziadé :
> Paul
>> I'd say that it's distutils' responsibility not to offer to uninstall
>> anything it didn't install.
>
> Brian
>> Yep. Though I think that nowdays dpkg installs to a different directory than
>> Distutils' default. So users have to specify extra options to break
>> t
On Thu, Jun 4, 2009 at 2:26 PM, Floris Bruynooghe
wrote:
>>
>> This is a dev version of a post-release version. Which is an edge case
>> submitted by Phillip.
>>
>> How would you write it ?
>
> 1.0.post623dev456 is what feels intuitive to me, here's my version of
> the last few lines:
>
> ... < V
Brian Sutherland wrote:
> 2009/6/4 Tarek Ziadé :
>
>> Oups messed up sorry -> resending my answer
>>
>> On Thu, Jun 4, 2009 at 11:52 AM, Brian Sutherland
>> wrote:
>>
- http://svn.python.org/projects/peps/trunk/pep-0386.txt
>>>... < V('1.0.dev456')
>>>... < V
Paul
> I'd say that it's distutils' responsibility not to offer to uninstall
> anything it didn't install.
Brian
> Yep. Though I think that nowdays dpkg installs to a different directory than
> Distutils' default. So users have to specify extra options to break
> their systems.
But how does those
2009/6/4 Tarek Ziadé :
> Oups messed up sorry -> resending my answer
>
> On Thu, Jun 4, 2009 at 11:52 AM, Brian Sutherland
> wrote:
>>> - http://svn.python.org/projects/peps/trunk/pep-0386.txt
>>
>> ... < V('1.0.dev456')
>> ... < V('1.0')
>> ... < V('1.0.dev456post623')
>>
>> Looks l
On Thu, Jun 04, 2009 at 12:57:12PM +0200, Tarek Ziadé wrote:
>
> On Thu, Jun 4, 2009 at 11:52 AM, Brian Sutherland
> wrote:
> >> - http://svn.python.org/projects/peps/trunk/pep-0386.txt
> >
> >... < V('1.0.dev456')
> >... < V('1.0')
> >... < V('1.0.dev456post623')
> >
> > Looks l
2009/6/4 Tarek Ziadé :
>>> - PEP 376 | status : waiting for Phillip complementary feedback (and
>>> anyone else of course)
>>
>>
>> I can imagine distutils uninstalling files previously installed by dpkg
>> as a shortcut to breaking a machine. Though I'm not sure what will
>> actually happen in pra
Oups messed up sorry -> resending my answer
On Thu, Jun 4, 2009 at 11:52 AM, Brian Sutherland
wrote:
>> - http://svn.python.org/projects/peps/trunk/pep-0386.txt
>
>... < V('1.0.dev456')
>... < V('1.0')
>... < V('1.0.dev456post623')
>
> Looks like a typo or very un-intuitive. It d
On Thu, Jun 04, 2009 at 11:17:38AM +0200, Tarek Ziad? wrote:
> Hello
>
> Here's a status of the current work waiting to be included in
> Distutils. (target: Python 2.7 and Python 3.2)
>
> I have created PEP 386 for the version comparison work, and gathered
> in it all the work related to version c
On Thu, Jun 04, 2009 at 11:17:38AM +0200, Tarek Ziad? wrote:
> Hello
>
> Here's a status of the current work waiting to be included in
> Distutils. (target: Python 2.7 and Python 3.2)
>
> I have created PEP 386 for the version comparison work, and gathered
> in it all the work related to version
Hello
Here's a status of the current work waiting to be included in
Distutils. (target: Python 2.7 and Python 3.2)
I have created PEP 386 for the version comparison work, and gathered
in it all the work related to version comparison,
I am not an Fedora, Ubuntu, [put your os here] specialist and
On Sat, May 30, 2009 at 07:27:06PM -0400, David Lyon wrote:
> On Fri, 29 May 2009 08:35:16 -0700, Andrew Straw
> wrote:
> > Brian Sutherland wrote:
> >> I've just published a very small library that does three things so far:
> >>
> >> * Provides a mapping between python project names and Debi
35 matches
Mail list logo
