Distutils-SIG June 2009

distutils-sig@python.org

57 participants
81 discussions

by Tarek Ziadé

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 the PEP is in its early stage, so it needs your feedback of you see false statements, incomplete info or errrors. STATUS: - new PEP 386 | waiting for your feedback - http://svn.python.org/projects/peps/trunk/pep-0386.txt - PEP 376 | status : waiting for Phillip complementary feedback (and anyone else of course) - up-to-date PEP proposal : http://bitbucket.org/tarek/pep376/src/tip/docs/pep-0376 - up-to-date prototype code for pkgutil : http://bitbucket.org/tarek/pep376/src/tip/pkgutil.py - PEP 345 | status : waiting for PEP 386 validation Regards Tarek -- Tarek Ziadé | http://ziade.org

12 years, 7 months

Re: [Distutils] Comparison semantics for alphanumeric components of a version number (was: Version comparison - round 2)

by P.J. Eby

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 than it actually needs to be: >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". The other use case I might've been concerned about would be "2.4-1dev-r623", which IIUC would be "2.4.post1.dev623" under RationalVersion. IOW, I'm not sure that a RationalVersion needs more than one each of "post" and "dev", nor that they need to be in any order other than "post, dev". I think there was some confusion on my part at first, because under setuptools' versioning scheme, "-r" is technically a "post-release" tag, but when used in a scheme like '1.0a1dev-r623', its only effect is to compare greater than '1.0a1dev623' - a version that wouldn't be used in that case, anyway! So, that has some effect on what suggest_version should do, but not so much on the core versioning scheme. Does that make anything clearer? I want to make sure we don't end up with any extra complication due to my terminology confusion early on.

12 years, 7 months

a --user option for develop?

by Sébastien Barthélemy

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 !

12 years, 7 months

Re: [Distutils] post-release tags and RationalVersion (Was: PEP 345, PEP 376, PEP 386)

by P.J. Eby

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 alternative to this would be to just >call it "2.4.20051127" (i.e. not a "post-release of 20051127" but a >"patch-level version of 20051127". 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 wrapper for that is then '2.4.1-1'. However, some projects (see Jean-Paul Calderone's recent questions here) have things like '2.4+1' as a patch level. Anyway, the point is that you can have a development of a patch level, and patch levels are considered distinct from dotted levels. >I guess where I'm going is: given that RationalVersion requires >post-release values to be numeric, it seems that a valid solution is >to just have an additional version element. So instead of "2.4-r123" >you use "2.4.123". Instead of "1.0c1-r456" you use "1.0c1.456". > >Is there any usage of a post-release that doesn't fit in this scheme? > >Is there a potential practical problem with getting users to switch to >that? E.g. Perhaps something with the setup.cfg config variables that >setuptools' versioning supports (I'm not that familiar with them)? I think we're going to have to stage the implementation on the setuptools side, first by switching tagging functions to a plugin-based operation, and second to provide optional version conversion/rationalization. I personally don't think it will ever make sense to *require* version rationalization, since Python is certainly used for private projects and companies may have their own numbering schemes. At most, we can warn about versions being potentially not-parseable or being not suitable for PyPI distribution if at some point PyPI can reasonably become strict about the matter.

12 years, 7 months

Re: [Distutils] PEP 345, PEP 376, PEP 386

by P.J. Eby

At 12:57 PM 6/4/2009 +0200, Tarek Ziadé wrote: >On Thu, Jun 4, 2009 at 11:52 AM, Brian Sutherland ><brian(a)vanguardistas.net> 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 a standard for an EGG-INFO structure, and provides a >API for the uninstallation that is more likely to be a reference >implementation. There probably needs to be an install option that prevents the file record from being written, and this option should be used when creating system packages. 3rd-party installation tools also should not overwrite or delete files that are not in a RECORD file without prompting or warning.

12 years, 7 months

post-release tags and RationalVersion (Was: PEP 345, PEP 376, PEP 386)

by Trent Mick

2009/6/4 P.J. Eby <pje(a)telecommunity.com> > > 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 that post-release version, will need the dev tagging to distinguish installed/development versions from each other, even if these intermediate versions are never "released" to PyPI. People working from checkouts will need them to keep their install/build tools happily humming along, able to tell which intermediate checkout version they're workign with and whether they are up-to-date. > Are there any such projects that people can point to? http://peak.telecommunity.com/DevCenter/setuptools says > A post-release tag is either a series of letters that are alphabetically greater than or equal to "final", or a dash (-). Post-release tags are generally used to separate patch numbers, port numbers, build numbers, revision numbers, or date stamps from the release number. For example, the version 2.4-r1263 might denote Subversion revision 1263 of a post-release patch of version 2.4. Or you might use 2.4-20051127 to denote a date-stamped post-release. > I wonder if there is too much potential for confusion here. The "2.4-r1263" example: I would interpret that to be a *pre*-release of version 2.4. However verlib.py's "suggest_rational_version" does suggest "2.4.post1263" for this. I guess that is fine, because the RationalVersion spelling (with the explicit "post") is more self-explanatory. 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 alternative to this would be to just call it "2.4.20051127" (i.e. not a "post-release of 20051127" but a "patch-level version of 20051127". I guess where I'm going is: given that RationalVersion requires post-release values to be numeric, it seems that a valid solution is to just have an additional version element. So instead of "2.4-r123" you use "2.4.123". Instead of "1.0c1-r456" you use "1.0c1.456". Is there any usage of a post-release that doesn't fit in this scheme? Is there a potential practical problem with getting users to switch to that? E.g. Perhaps something with the setup.cfg config variables that setuptools' versioning supports (I'm not that familiar with them)? Trent -- Trent Mick trentm(a)gmail.com

12 years, 7 months

Re: [Distutils] PEP 345, PEP 376, PEP 386

by P.J. Eby

At 03:02 PM 6/4/2009 +0200, Tarek Ziadé wrote: >On Thu, Jun 4, 2009 at 2:26 PM, Floris Bruynooghe ><floris.bruynooghe(a)gmail.com> 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('1.0') > > ... < V('1.0.post456dev623') > > ... < V('1.0.post456')) > > > > It would even feel more consistent if it was 1.0.port456.dev623 > >Sounds reasonable, I'll try something in the prototype, and submit it here > > > > > > > Frankly I don't really understand the post-release requirement (and > > the PEP text doesn't help me out there, no explenation of what it is). > >Being able to create development releases versions before a post-release >Phillip Eby came with this use case, you should find the original >message in the ML somewhere. Development before postrelease = "1.0post456dev623" In-progress snapshot of development version = "1.0dev456post623" 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". Hopefully, all these examples I've just given are correct and work with the versioning code, as that would still be a strict subset of setuptools.

12 years, 7 months

Re: [Distutils] PEP 345, PEP 376, PEP 386

by 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 multiple commits required to create that post-release version, will need the dev tagging to distinguish installed/development versions from each other, even if these intermediate versions are never "released" to PyPI. People working from checkouts will need them to keep their install/build tools happily humming along, able to tell which intermediate checkout version they're workign with and whether they are up-to-date.

12 years, 7 months

Re: [Distutils] PEP 345, PEP 376, PEP 386

by P.J. Eby

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.log files installed by >bdist_wininst. The system would then still think that the package was >installed, even though it isn't. (And the system uninstall may break - >I'm not sure). A bdist_wininst should skip the RECORD file in that case. The RECORD file should still be *in* the installer zip, though, in case someone unpacks it manually. (Alternatively, perhaps there should be some way to record who/what installed the package, and how it should be uninstalled.)

12 years, 7 months

Re: [Distutils] PEP 345, PEP 376, PEP 386

by 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 incorrect to me; it should be a post-release of a development version, analagous to ".dev456-r623" in a setuptools version. I think it would also be helpful to note that one of the new scheme's design goals is to be a strict subset of the setuptools version algorithm; you sort of implied it in a couple of places (talking about the widespread use, and the problem of interpreting such a wide variety of schemes), but it might be good to point that out, so it's clear that adopting the scheme for your package will not require opting out of the setuptools-based infrastructure or depriving anyone of their preferred tools. (In that vein, it also might be helpful to suggest that people try using parse_version() comparisons to verify that their new numbers are all > their old numbers, if they plan to change schemes. Despite the strict-subset property, there might be problems in the case where they are not currently using an equivalent subset.) >- PEP 376 | status : waiting for Phillip complementary feedback (and >anyone else of course) > > - up-to-date PEP proposal : >http://bitbucket.org/tarek/pep376/src/tip/docs/pep-0376 > - up-to-date prototype code for pkgutil : >http://bitbucket.org/tarek/pep376/src/tip/pkgutil.py I'll try to look at this again soon, probably the weekend.

12 years, 7 months

← Newer
1
2
3
4
5
6
7
8
9
Older →

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

Distutils-SIG June 2009