Op 06-01-13 23:03, Jim Fulton schreef:
On Sun, Jan 6, 2013 at 3:51 PM, Reinout van Rees 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 configuration
file. It is
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 can
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 ve
At Mon, 31 Dec 2012 18:59:19 + (UTC),
Vinay Sajip wrote:
>
> Jeroen Dekkers 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 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 current python stack)
On Sun, Jan 6, 2013 at 7:38 PM, Alex Clark 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
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 name of
>> a
On Mon, Jan 7, 2013 at 7:34 AM, Leonardo Rochael Almeida
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 features:
>
>
Jeroen Dekkers 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 relative or absolute paths
> are used is decided by the tool that creates/modifie
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
Op 07-01-13 15:42, Jim Fulton schreef:
On Mon, Jan 7, 2013 at 6:12 AM, Maurits van Rees
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 update-v-f result
false false
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, the
On 7 January 2013 14:40, Vinay Sajip wrote:
> Jeroen Dekkers 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 relative or absolute paths
>>
On Mon, Jan 7, 2013 at 12:57 PM, Marius Gedminas 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 output of "b
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 wrote:
> 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 synt
> From: Paul Moore
> 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 states at present.
On 7 January 2013 16:37, Vinay Sajip 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 neither (!) pur
On Mon, Jan 7, 2013 at 9:57 AM, Marius Gedminas 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 version
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 p
On Sat, Jan 5, 2013 at 11:47 PM, Jim Fulton 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 information.
Multi
21 matches
Mail list logo
