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
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.
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 !
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.
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.
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
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.
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.
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.)
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.