On 20 July 2013 03:18, Daniel Holth dho...@gmail.com wrote:
On Fri, Jul 19, 2013 at 11:23 AM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
I would really like to see one more level of nesting:
requires : { run : [ ... ], test : [ ... ] }
I've already changed distlib's code several times
I would really like to see one more level of nesting:
requires : { run : [ ... ], test : [ ... ] }
I've already changed distlib's code several times as the spec has evolved, and
would like not to see any more changes so that I can concentrate on some real
work ;-)
Seriously, what's
On Fri, Jul 5, 2013 at 4:25 AM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Nick Coghlan ncoghlan at gmail.com writes:
The basic problem with the list form is that allowing two representations
for the same metadata makes for extra complexity we don't really want. It
means we have to decide if
On Fri, Jul 19, 2013 at 11:23 AM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
I would really like to see one more level of nesting:
requires : { run : [ ... ], test : [ ... ] }
I've already changed distlib's code several times as the spec has evolved,
and would like not to see any more
Nick Coghlan ncoghlan at gmail.com writes:
The basic problem with the list form is that allowing two representations
for the same metadata makes for extra complexity we don't really want. It
means we have to decide if the decomposed version (3 separate entries
with one item in each install
Nick Coghlan ncoghlan at gmail.com writes:
* install: the installation specifier for the dependency
* extra: as per the current PEP (for conditional dependencies)
* environment: as per the current PEP (for conditional dependencies)
4. The install subfield is compulsory, the other two are
On 4 Jul 2013 18:52, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Nick Coghlan ncoghlan at gmail.com writes:
* install: the installation specifier for the dependency
* extra: as per the current PEP (for conditional dependencies)
* environment: as per the current PEP (for conditional
On Jul 4, 2013, at 7:00 AM, Nick Coghlan ncogh...@gmail.com wrote:
On 4 Jul 2013 18:52, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Nick Coghlan ncoghlan at gmail.com writes:
* install: the installation specifier for the dependency
* extra: as per the current PEP (for conditional
On 4 Jul 2013 21:35, Donald Stufft don...@stufft.io wrote:
On Jul 4, 2013, at 7:00 AM, Nick Coghlan ncogh...@gmail.com wrote:
On 4 Jul 2013 18:52, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Nick Coghlan ncoghlan at gmail.com writes:
* install: the installation specifier for the
Donald Stufft donald at stufft.io writes:
I would prefer a single entry. It makes the serialization format map to the
modeling simpler, and I think it's simpler for humans too. I don't see much
benefit to making it a list except arbitrarily adding another level of
nesting.
It's a question of
On Jul 4, 2013, at 8:31 AM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Donald Stufft donald at stufft.io writes:
I would prefer a single entry. It makes the serialization format map to the
modeling simpler, and I think it's simpler for humans too. I don't see much
benefit to making it a
I also prefer the list install : []
Have you played with Postgresql's JSON support :-)
On Thu, Jul 4, 2013 at 8:37 AM, Donald Stufft don...@stufft.io wrote:
On Jul 4, 2013, at 8:31 AM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Donald Stufft donald at stufft.io writes:
I would prefer a
Yea. It's slow and requires invoking plv8 to do much of anything useful ;)
On Jul 4, 2013, at 9:23 AM, Daniel Holth dho...@gmail.com wrote:
Have you played with Postgresql's JSON support :-)
___
Distutils-SIG maillist - Distutils-SIG@python.org
If you don't waste your time enforcing the uniqueness of (condition,
extra) in the list of requirements then you can pretend install: is a
single item if you want to...
Wheel converts the flat Metadata 1.3 format to 2.0 draft easily with a
defaultdict:
Yea I just spent significant effort cleaning up the database from a lack if
enforced constraints. I will pass on not using them.
On Jul 4, 2013, at 9:34 AM, Daniel Holth dho...@gmail.com wrote:
If you don't waste your time enforcing the uniqueness of (condition,
extra) in the list of
On Thu, Jul 4, 2013 at 9:36 AM, Donald Stufft don...@stufft.io wrote:
Yea I just spent significant effort cleaning up the database from a lack if
enforced constraints. I will pass on not using them.
On Jul 4, 2013, at 9:34 AM, Daniel Holth dho...@gmail.com wrote:
If you don't waste your
Nick Coghlan ncoghlan at gmail.com writes:
The main benefit is that all the dependencies for an extra will typically
be in one place.
However, I briefly forgot the machine readable part again, and for that
TOOWTDI is to have one entry per dependency.
One record per dependency is indeed the
On the plus side if we're arguing about something as banal as this,
maybe we are almost done!
On Thu, Jul 4, 2013 at 3:38 PM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Nick Coghlan ncoghlan at gmail.com writes:
The main benefit is that all the dependencies for an extra will typically
be in
On Thu, Jul 4, 2013 at 8:24 PM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Daniel Holth dholth at gmail.com writes:
On the plus side if we're arguing about something as banal as this,
maybe we are almost done!
I don't exactly see it as an argument - it's just a discussion (although of
On 4 Jul 2013 22:32, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Donald Stufft donald at stufft.io writes:
I would prefer a single entry. It makes the serialization format map to
the
modeling simpler, and I think it's simpler for humans too. I don't see
much
benefit to making it a list
On Jul 4, 2013, at 9:45 PM, Nick Coghlan ncogh...@gmail.com wrote:
What I will do is draft PEP text for the list version that explicitly
declares the decomposed form non-compliant with the spec. If I think the
extra complexity looks tolerable, I'll switch it over.
What is the
I don't think you can get around the complexity. Consider:
{extra:'foo', condition:'platform == win32', install=[]}
{extra:'foo', condition:'platform == linux', install=[]}
They have to be flattened into a single list of all the 'foo' extras
that are installable in the current environment
Nick Coghlan ncoghlan at gmail.com writes:
Donald has been continuing his data modelling work for Warehouse (aka
PyPI 2.0: https://github.com/dstufft/warehouse) and found that the
*_requires/*_may_require split for dependencies was significantly more
painful to work with than I had expected.
On 30 June 2013 17:44, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Nick Coghlan ncoghlan at gmail.com writes:
Donald has been continuing his data modelling work for Warehouse (aka
PyPI 2.0: https://github.com/dstufft/warehouse) and found that the
*_requires/*_may_require split for dependencies
Nick Coghlan ncoghlan at gmail.com writes:
No, because the semantic dependencies form a Cartesian product with
the extras. You can define :meta:, :run:, :test:, :build: and :dev:
dependencies for any extra. So if, for example, you have a localweb
extra, then you can define extra test
On 30 June 2013 18:53, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Nick Coghlan ncoghlan at gmail.com writes:
No, because the semantic dependencies form a Cartesian product with
the extras. You can define :meta:, :run:, :test:, :build: and :dev:
dependencies for any extra. So if, for example,
On Jun 30, 2013, at 7:21 AM, Nick Coghlan ncogh...@gmail.com wrote:
On 30 June 2013 18:53, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Nick Coghlan ncoghlan at gmail.com writes:
No, because the semantic dependencies form a Cartesian product with
the extras. You can define :meta:, :run:,
Sun, Jun 30, 2013 at 12:47 PM, Donald Stufft don...@stufft.io wrote:
On Jun 30, 2013, at 7:21 AM, Nick Coghlan ncogh...@gmail.com wrote:
On 30 June 2013 18:53, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Nick Coghlan ncoghlan at gmail.com writes:
No, because the semantic dependencies form a
On Jun 30, 2013, at 4:26 PM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Donald Stufft donald at stufft.io writes:
While the two forms are functionally equivalent, I still prefer
multiple top level fields, as I consider it both easier to document
and more consistent with the approach used
Donald Stufft donald at stufft.io writes:
I'm not worried about the speed or performance, I'm worried about how
annoying it is to write a tool that processes it.
Quite possibly I misunderstood the thrust of your argument, but the point of
distlib is to take care of those kinds of low-level
On Jun 30, 2013, at 4:47 PM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Donald Stufft donald at stufft.io writes:
I'm not worried about the speed or performance, I'm worried about how
annoying it is to write a tool that processes it.
Quite possibly I misunderstood the thrust of your
On Sun, 30 Jun 2013 21:21:54 +1000, Nick Coghlan wrote:
On 30 June 2013 18:53, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Nick Coghlan ncoghlan at gmail.com writes:
No, because the semantic dependencies form a Cartesian product with
the extras. You can define :meta:, :run:, :test:, :build:
On Jun 30, 2013, at 6:39 PM, Gabriel de Perthuis g2p.c...@gmail.com wrote:
So it would prefer that dev and test be extras with well known names,
so that dev, test, and any other extras define dependencies with a
minimum of ambiguity and without the need for a second level of
qualifiers.
On Sun, 30 Jun 2013 18:46:51 -0400, Donald Stufft wrote:
On Jun 30, 2013, at 6:39 PM, Gabriel de Perthuis g2p.c...@gmail.com wrote:
So it would prefer that dev and test be extras with well known names,
so that dev, test, and any other extras define dependencies with a
minimum of ambiguity
On Jun 30, 2013, at 6:51 PM, Gabriel de Perthuis g2p.c...@gmail.com wrote:
On Sun, 30 Jun 2013 18:46:51 -0400, Donald Stufft wrote:
On Jun 30, 2013, at 6:39 PM, Gabriel de Perthuis g2p.c...@gmail.com wrote:
So it would prefer that dev and test be extras with well known names,
so that dev,
On Sun, 30 Jun 2013 18:52:46 -0400, Donald Stufft wrote:
On Jun 30, 2013, at 6:51 PM, Gabriel de Perthuis g2p.c...@gmail.com wrote:
On Sun, 30 Jun 2013 18:46:51 -0400, Donald Stufft wrote:
On Jun 30, 2013, at 6:39 PM, Gabriel de Perthuis g2p.c...@gmail.com wrote:
So it would prefer that dev
On Jun 30, 2013, at 6:58 PM, Gabriel de Perthuis g2p.c...@gmail.com wrote:
On Sun, 30 Jun 2013 18:52:46 -0400, Donald Stufft wrote:
On Jun 30, 2013, at 6:51 PM, Gabriel de Perthuis g2p.c...@gmail.com wrote:
On Sun, 30 Jun 2013 18:46:51 -0400, Donald Stufft wrote:
On Jun 30, 2013, at 6:39 PM,
On 1 Jul 2013 08:40, Gabriel de Perthuis g2p.c...@gmail.com wrote:
On Sun, 30 Jun 2013 21:21:54 +1000, Nick Coghlan wrote:
On 30 June 2013 18:53, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Nick Coghlan ncoghlan at gmail.com writes:
No, because the semantic dependencies form a Cartesian
Donald has been continuing his data modelling work for Warehouse (aka
PyPI 2.0: https://github.com/dstufft/warehouse) and found that the
*_requires/*_may_require split for dependencies was significantly more
painful to work with than I had expected.
Accordingly, I'm making some adjustments to the
39 matches
Mail list logo
