Chris Withers a écrit :
Alex Rades wrote:
This is actually even quicker and simpler than it looks.
[complex-deps]
interpreter = python
recipe = minitage.recipe.scripts
urls =
http://media.djangoproject.com/releases/1.1.1/Django-1.1.1.tar.gz
kiorky wrote:
${buildout:directory}/patches/debug_toolbar_sqlpanel.diff
This kind of patching makes me nervous...
why ? patches are a common way to 'patch' code.
Maybe 10 years ago. With a DVCS, or even a non-d VCS for that matter,
why would you need to apply patches like this, which
Chris Withers a écrit :
kiorky wrote:
${buildout:directory}/patches/debug_toolbar_sqlpanel.diff
This kind of patching makes me nervous...
why ? patches are a common way to 'patch' code.
Maybe 10 years ago. With a DVCS, or even a non-d VCS for that matter,
why would you need to apply
[Tarek Ziadé, 2009-11-26]
On Thu, Nov 26, 2009 at 8:55 PM, Floris Bruynooghe
floris.bruynoo...@gmail.com wrote:
[..]
since the .dev versions are really only snapshots leading up to
some release, i.e. 1.0.dev456 is a snapshot leading up to the
first pre-release of the 1.0 :-)
But in
Hi All,
Do you guys on this lists have any ideas how packages can indicate to
package managers like setuptools could indicate that if they are
required by another package, that requirement must be for greater than a
certain version?
This stems from the backwards compatibility discussion for
On Fri, Nov 27, 2009 at 11:39 AM, Piotr Ozarowski oza...@gmail.com wrote:
[Tarek Ziadé, 2009-11-26]
On Thu, Nov 26, 2009 at 8:55 PM, Floris Bruynooghe
floris.bruynoo...@gmail.com wrote:
[..]
since the .dev versions are really only snapshots leading up to
some release, i.e. 1.0.dev456 is a
On Fri, Nov 27, 2009 at 1:24 PM, Tarek Ziadé ziade.ta...@gmail.com wrote:
[..]
don't worry about Debian, we'll simply replace - with ~ (we use ~
and + right now[0]). I'm not sure about rpm, but I bet it has
something similar and it will be much easier for us to simply handle two
characters
Tarek Ziadé ziade.ta...@gmail.com writes:
That makes me think that a nice add-on to the lib and the PEP would be
to provide APIs to translate a Python PEP 386 version to a
Debian/Ubuntu or RPM ones - and any major packaging system out there.
(whatever scheme we pick)
I'd like to register,
[Tarek Ziadé, 2009-11-27]
On Fri, Nov 27, 2009 at 1:24 PM, Tarek Ziadé ziade.ta...@gmail.com wrote:
[..]
don't worry about Debian, we'll simply replace - with ~ (we use ~
and + right now[0]). I'm not sure about rpm, but I bet it has
something similar and it will be much easier for us to
On Nov 27, 2009, at 7:31 AM, Tarek Ziadé wrote:
On Fri, Nov 27, 2009 at 1:24 PM, Tarek Ziadé ziade.ta...@gmail.com wrote:
[..]
don't worry about Debian, we'll simply replace - with ~ (we use ~
and + right now[0]). I'm not sure about rpm, but I bet it has
something similar and it will be
On Fri, Nov 27, 2009 at 3:31 PM, sstein...@gmail.com
sstein...@gmail.com wrote:
On Nov 27, 2009, at 7:31 AM, Tarek Ziadé wrote:
On Fri, Nov 27, 2009 at 1:24 PM, Tarek Ziadé ziade.ta...@gmail.com wrote:
[..]
don't worry about Debian, we'll simply replace - with ~ (we use ~
and + right
simply bump epoch so after 20091127-1
comes 1:5.6.7-1, how would you know that epoch bump was needed without
knowing the history of the package?
We cannot really trust versions in requires.txt/install_requires/etc.
either (so there's no need to translate them) as we have to double check
On Nov 27, 2009, at 9:41 AM, Tarek Ziadé wrote:
I'm still very interested in the increment_version functionality we talked
about earlier so that we could have our build process automatically up our
release version numbers so we have a standard way of maintaining incremental
versioning.
On Nov 27, 2009, at 9:58 AM, Piotr Ozarowski wrote:
[sstein...@gmail.com, 2009-11-27]
That makes me think that a nice add-on to the lib and the PEP would be
to provide APIs to translate a Python PEP 386 version to a Debian/Ubuntu or
RPM ones -
and any major packaging system out there.
Tarek Ziadé ziade.ta...@gmail.com writes:
On Fri, Nov 27, 2009 at 1:52 PM, Ben Finney ben+pyt...@benfinney.id.au
wrote:
I'd like to register, once again, the point that [translating PEP
386 version comparison semantics to existing semantics] would not
*be* a problem if PEP 386 described
Ben Finney wrote:
Yes, and others that have been proposed to be exceptions to alphanumeric
ordering.
the problem we have is to be able to sort those post and pre releases
with other versions. And this is not possible with a simple
alphanumerical comparison.
It is, if the version strings are
Eric Smith e...@trueblade.com writes:
Ben Finney wrote:
the problem we have is to be able to sort those post and pre
releases with other versions. And this is not possible with a
simple alphanumerical comparison.
It is, if the version strings are chosen to fit within such a
At 10:32 AM 11/28/2009 +1100, Ben Finney wrote:
This is a red herring, AFAICT. It's been discussed already that
workflow is orthogonal to version comparison semantics. That is,
nothing about a workflow involving snapshots or dev versions etc.
implies that exceptional version keywords need to
P.J. Eby p...@telecommunity.com writes:
At 10:32 AM 11/28/2009 +1100, Ben Finney wrote:
Moreover, AIUI there is no injunction that all projects must follow
exactly the semantics of PEP 386, right? So why not have a *simple*
standard (all version string components compared alphanumerically)
Ben Finney wrote:
Eric Smith e...@trueblade.com writes:
Ben Finney wrote:
the problem we have is to be able to sort those post and pre
releases with other versions. And this is not possible with a
simple alphanumerical comparison.
It is, if the version strings are chosen to fit within such a
At 12:26 PM 11/28/2009 +1100, Ben Finney wrote:
I think you're reading a proposal that I didn't write.
Are you not the person who's proposed using simple alphanumeric
strings for version comparison?
My understanding of PEP 386 is that it *isn't* about asking Python
developers to change how
It occurs to me that this problem would go away if we had a way to
ask, for any given version number, 'what was your creation date' and
the sorting 'earlier' and 'later' by that date. Can somebody explain
why we aren't doing this?
Laura
___
Eric Smith e...@trueblade.com writes:
Ben Finney wrote:
Since the specification is about version *comparison* semantics, I'd
need to know example version strings that should compare “prior” and
“subsequent” for the version string I'm to propose. Can you give
examples?
I want to install
23 matches
Mail list logo
