On 28 September 2012 18:05, Nick Coghlan ncogh...@gmail.com wrote:
On Fri, Sep 28, 2012 at 10:07 AM, Daniel Holth dho...@gmail.com wrote:
Are we trying to kill setuptools? I'm not entirely sure, but we should
stop trying to do that. The migration should take essentially forever
as soon as it
On Mon, Oct 1, 2012 at 8:22 PM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
David Cournapeau cournape at gmail.com writes:
I noticed that you put the classifiers list as a string (same for
platform). I think it is expected to be a list, no ?
That's an oversight; there are doubtless others,
On Thu, Oct 4, 2012 at 8:55 AM, Paul Moore p.f.mo...@gmail.com wrote:
On 28 September 2012 18:05, Nick Coghlan ncogh...@gmail.com wrote:
On Fri, Sep 28, 2012 at 10:07 AM, Daniel Holth dho...@gmail.com wrote:
Are we trying to kill setuptools? I'm not entirely sure, but we should
stop trying to
On Thu, Oct 4, 2012 at 6:25 PM, Paul Moore p.f.mo...@gmail.com wrote:
2. Some level of standardised functionality for building and
installing. By standardised, I mean that given *any* sdist, no
matter what build tool it uses under the scenes, there is a way of
saying build this, and put the
On Mon, Oct 1, 2012 at 12:40 AM, Donald Stufft donald.stu...@gmail.com wrote:
On Sunday, September 30, 2012 at 6:50 PM, David Cournapeau wrote:
I am not sure I understand the argument: whatever the syntax, if the
feature is there, you will have the same problem ? The fact that it is
used by
David Cournapeau cournape at gmail.com writes:
I am not suggesting something very complicated (we don't want to
re-create a language), but more something like cabal (see conditionals
in
http://www.haskell.org/cabal/users-guide/developing-packages.html#package-descriptions),
or even RPM
On Mon, Oct 1, 2012 at 8:14 AM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
David Cournapeau cournape at gmail.com writes:
I am not suggesting something very complicated (we don't want to
re-create a language), but more something like cabal (see conditionals
in
David Cournapeau cournape at gmail.com writes:
Note that in Cabal at least, those conditionals work not just for
requirements, but for pretty much any section that is not metadata (so
in the python world, you could condition on the package you want to
install, etc...).
Right, but the concept
On Mon, Oct 1, 2012 at 3:15 PM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
David Cournapeau cournape at gmail.com writes:
Note that in Cabal at least, those conditionals work not just for
requirements, but for pretty much any section that is not metadata (so
in the python world, you could
] [Python-Dev] distlib updated with resources API
Have you read the IPython setup.py?
https://github.com/ipython/ipython/blob/master/setup.py
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
David Cournapeau cournape at gmail.com writes:
The code that produces yaml files. The point is precisely that it
would be easy for me to consume this and produce the internal package
representation in bento, which would then allow to configure, build
and install packages using the bento
On Mon, Oct 1, 2012 at 5:06 PM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
David Cournapeau cournape at gmail.com writes:
The code that produces yaml files. The point is precisely that it
would be easy for me to consume this and produce the internal package
representation in bento, which
David Cournapeau cournape at gmail.com writes:
I noticed that you put the classifiers list as a string (same for
platform). I think it is expected to be a list, no ?
That's an oversight; there are doubtless others, too.
Maybe slightly more controversial, I think the manifest should be
On Sunday, September 30, 2012 at 1:33 AM, Daniel Holth wrote:
Why not just let any line in pkg-info that starts with json/tag name: decode
as json.
Why use a format that requires custom parsing knowledge to create an internal
Python representation. It cannot even accurately represent all of
On Sep 30, 2012, at 2:07 AM, Donald Stufft donald.stu...@gmail.com wrote:
On Sunday, September 30, 2012 at 1:33 AM, Daniel Holth wrote:
Why not just let any line in pkg-info that starts with json/tag name: decode
as json.
Why use a format that requires custom parsing knowledge to create an
On Sun, Sep 30, 2012 at 6:03 AM, Donald Stufft donald.stu...@gmail.com wrote:
I have some unpublished work I should publish.
Part of the point with what i'm trying to do is to define a standard for
what is inside
a package, but not really for how you take a particular set of files and
turn
On Sun, Sep 30, 2012 at 4:55 AM, Daniel Holth dho...@gmail.com wrote:
I like this kind of study. Fixing 1300 packages sounds a lot more
manageable than fixing 18,000. (I took a similar look at setup.py but
with the ast module instead of actually running the things. Your
method is probably more
On Sun, Sep 30, 2012 at 8:59 AM, David Cournapeau courn...@gmail.com wrote:
On Sun, Sep 30, 2012 at 6:03 AM, Donald Stufft donald.stu...@gmail.com
wrote:
I have some unpublished work I should publish.
Part of the point with what i'm trying to do is to define a standard for
what is inside
a
David Cournapeau cournape at gmail.com writes:
Note that being able to convert a package does not mean the conversion
is working. You need to make sure that installing something from this
new format gives the same thing as installing from the setup.py.
That's harder to test, obviously.
On Sunday, September 30, 2012 at 8:59 AM, David Cournapeau wrote:
Note that all this work has already been done in Bento.
I understand the appeal of using an existing format like yaml, but it
is not clear to me how one can handle conditional with it, and I think
you want to handle
It's the same. Someone will write a bento conditionals to pep markers
compiler and it will be trivial.
On Sep 30, 2012 12:07 PM, Donald Stufft donald.stu...@gmail.com wrote:
On Sunday, September 30, 2012 at 8:59 AM, David Cournapeau wrote:
Note that all this work has already been done in
On Sunday, September 30, 2012 at 12:38 PM, Daniel Holth wrote:
It's the same. Someone will write a bento conditionals to pep markers
compiler and it will be trivial.
Right same concept, the difference being one requires a specialized parser and
the other uses a standard parser available
On Sun, Sep 30, 2012 at 5:07 PM, Donald Stufft donald.stu...@gmail.com wrote:
On Sunday, September 30, 2012 at 8:59 AM, David Cournapeau wrote:
Note that all this work has already been done in Bento.
I understand the appeal of using an existing format like yaml, but it
is not clear to me how
On Sunday, September 30, 2012 at 6:21 PM, David Cournapeau wrote:
Right, in that case, it would work, but in my experience, it is
important to be able to apply conditionals to more than just
requirements (packages definition and so on).
A significant problem is caused by the allowance of if
On Sun, Sep 30, 2012 at 11:35 PM, Donald Stufft donald.stu...@gmail.com wrote:
On Sunday, September 30, 2012 at 6:21 PM, David Cournapeau wrote:
Right, in that case, it would work, but in my experience, it is
important to be able to apply conditionals to more than just
requirements (packages
On Sunday, September 30, 2012 at 6:50 PM, David Cournapeau wrote:
I am not sure I understand the argument: whatever the syntax, if the
feature is there, you will have the same problem ? The fact that it is
used by existing solutions tend to convince me it is not a problem
(cabal works much
On Sun, Sep 30, 2012 at 7:40 PM, Donald Stufft donald.stu...@gmail.com wrote:
On Sunday, September 30, 2012 at 6:50 PM, David Cournapeau wrote:
I am not sure I understand the argument: whatever the syntax, if the
feature is there, you will have the same problem ? The fact that it is
used by
Nick Coghlan ncoghlan at gmail.com writes:
The document has changed since then,
http://python-notes.boredomandlaziness.org/en/latest/pep_ideas/core_packaging_api.html
I read from your page there that Donald Stufft is working on a JSON-based
metadata format. I've been looking that the same
I like this kind of study. Fixing 1300 packages sounds a lot more
manageable than fixing 18,000. (I took a similar look at setup.py but
with the ast module instead of actually running the things. Your
method is probably more accurate.) It would be very cool to know how
many packages use if:
I have some unpublished work I should publish.
Part of the point with what i'm trying to do is to define a standard for what
is inside
a package, but not really for how you take a particular set of files and turn
it into
that. So if you want to edit yaml you can have a yaml file and have a
Why not just let any line in pkg-info that starts with json/tag name: decode as
json.
On Sep 30, 2012, at 1:03 AM, Donald Stufft donald.stu...@gmail.com wrote:
I have some unpublished work I should publish.
Part of the point with what i'm trying to do is to define a standard for what
is
On Fri, Sep 28, 2012 at 10:07 AM, Daniel Holth dho...@gmail.com wrote:
Are we trying to kill setuptools? I'm not entirely sure, but we should
stop trying to do that. The migration should take essentially forever
as soon as it makes sense for each pypi publisher.
I'd certainly like to kill
I'd certainly like to kill easy_install, and see any popular elements
of setuptools metadata become officially defined *independently* of
any given implementation.
I would like to kill distutils without killing setuptools, if that
makes any sense.
I think the most important thing to do is to
On Fri, Sep 28, 2012 at 9:37 AM, Tarek Ziadé ta...@ziade.org wrote:
On 9/28/12 12:55 AM, Antoine Pitrou wrote:
Last but not least, distlib is the plan forward endorsed by python-dev,
Is it? I haven't seen a PEP or an official decision about that. Just
because
someone proposed it on a
The wheel strategy has just been to implement the peps in setuptools
and in pkg_resources. It is nearly effortless to do so since the PEPs
are so similar to the existing system of eggs. Plus you get to play
with it using 900 * 1.6 ** (year-2005) packages.
Afterwards, with binary packages, you can
35 matches
Mail list logo
