Op 06-01-13 23:03, Jim Fulton schreef:
On Sun, Jan 6, 2013 at 3:51 PM, Reinout van Rees rein...@vanrees.org wrote:
On 05-01-13 23:47, Jim Fulton wrote:
1. New buildout option named ``versions-file`` which takes the name of
a file. to contain version information. It is not a
Op 05-01-13 23:47, Jim Fulton schreef:
Lots of people agree that buildout-versions us useful
and the author has volunteered to contribute it to core buildout.
Cool!
Of course, as a part of buildout, rather than an extension, it can be
streamlined a bit. Also, based on experience, I think we
Hi
I see one major issue with this proposal:
Currently, the fact that the versions are in a standard buildout
section, and subject to standard extends layering rules for
buildout, means we have two great features:
1. You could locally override the versions file by just providing a
few extra
At Mon, 31 Dec 2012 18:59:19 + (UTC),
Vinay Sajip wrote:
Jeroen Dekkers jeroen at dekkers.ch writes:
I agree that having the paths relative to the parent directory of the
.dist-info directory is preferable. It's easy to implement and I don't
really see any downsides at the moment.
At Fri, 4 Jan 2013 11:43:13 +,
Paul Moore wrote:
On 4 January 2013 11:06, Antonio Cavallo a.cava...@cavallinux.eu wrote:
And I'm talking about **applications** (eg. some code + some library
depending on an installed python stack) vs **libraries** (code simply
installed along the
On Sun, Jan 6, 2013 at 7:38 PM, Alex Clark acl...@aclark.net wrote:
On 2013-01-05 22:47:05 +, Jim Fulton said:
...
versions = versions
[versions]
...
This is confusing… but I was thinking more along the lines of adding a
default setting versions = versions, at which point end
On Mon, Jan 7, 2013 at 6:12 AM, Maurits van Rees
m.van.r...@zestsoftware.nl wrote:
Op 05-01-13 23:47, Jim Fulton schreef:
...
Based on this, I propose that buildout-versions get incorporated into
buildout in the following way:
1. New buildout option named ``versions-file`` which takes the
On Mon, Jan 7, 2013 at 7:34 AM, Leonardo Rochael Almeida
leoroch...@gmail.com wrote:
Hi
I see one major issue with this proposal:
Currently, the fact that the versions are in a standard buildout
section, and subject to standard extends layering rules for
buildout, means we have two great
On Mon, Jan 07, 2013 at 09:45:58AM -0500, Jim Fulton wrote:
No. The versions-file can be used with the existing mechanism.
I tried, but apparently failed, to make this clear in the proposal.
If both a versions file and a versions section is used, the versions
section behaves as it does now
Op 07-01-13 15:42, Jim Fulton schreef:
On Mon, Jan 7, 2013 at 6:12 AM, Maurits van Rees
m.van.r...@zestsoftware.nl wrote:
Say there is a buildout config with one or more versions that are not
pinned. What would the effect be of the various options? Here is a truth
table:
allow-p-v
Op 07-01-13 15:57, Marius Gedminas schreef:
On Mon, Jan 07, 2013 at 09:45:58AM -0500, Jim Fulton wrote:
No. The versions-file can be used with the existing mechanism.
I tried, but apparently failed, to make this clear in the proposal.
If both a versions file and a versions section is used,
On 7 January 2013 14:40, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Jeroen Dekkers jeroen at dekkers.ch writes:
We can specify that paths in RECORDS can be relative to the parent
directory of the .dist-info directory or absolute and both must be
supported by installation tools. Whether
On Mon, Jan 7, 2013 at 12:57 PM, Marius Gedminas mar...@pov.lt wrote:
[...]
Also, having two similar but slightly distinct mechanisms for version
pinning? I'm -1 on that.
Yeah, that too (so, overall, a -2 from me :-)
It's one more place to check for/maintain version pin information.
The
Hi folks,
I recognized a glitch with pip when using the --upgrade option.
From the traceback:
File ./setuptools/dist.py, line 103
except ValueError, e:
^
SyntaxError: invalid syntax
This seems to happen only if --upgrade is used, regardless whether
a
On Mon, Jan 7, 2013 at 4:49 PM, Christian Tismer tis...@stackless.comwrote:
Hi folks,
I recognized a glitch with pip when using the --upgrade option.
From the traceback:
File ./setuptools/dist.py, line 103
except ValueError, e:
^
SyntaxError:
From: Paul Moore p.f.mo...@gmail.com
OK, that sounds like a good approach then. It might be worth noting
that relative paths are to be preferred wherever sensible (but that's
a recommendation only, not a requirement). But as I noted at the start
of this thread, it is *not* what PEP 376
On 7 January 2013 16:37, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
changed to be worded in terms of sysconfig-style locations: the
dist-info directory is located in whichever of purelib or platlib is
used by the distribution. When the distribution uses both, purelib is
preferred, when it uses
On Mon, Jan 7, 2013 at 9:57 AM, Marius Gedminas mar...@pov.lt wrote:
On Mon, Jan 07, 2013 at 09:45:58AM -0500, Jim Fulton wrote:
No. The versions-file can be used with the existing mechanism.
I tried, but apparently failed, to make this clear in the proposal.
If both a versions file and a
The distinction is useful in the life cycle context: an application
could depend on newer/older libraries than the one installed on the
system.
django-admin is an application from this life-cycle point of view.
Django is distributed as an application that contains its own library
(the
On Sat, Jan 5, 2013 at 11:47 PM, Jim Fulton j...@zope.com wrote:
Hi Jim
Based on this, I propose that buildout-versions get incorporated into
buildout in the following way:
Cool.
1. New buildout option named ``versions-file`` which takes the name of
a file. to contain version
20 matches
Mail list logo
