I've decided I'm really not happy with the current approach to
extension fields in PEP 426. It's ugly, clunky, inflexible and is hard
to cleanly convert to more structured metadata.
Here's the current example from the PEP:
Extension: Chili
Chili/Type: Poblano
Chili/Heat: Mild
Here's
I'm probably the only one but I'm not a fan of JSON with all the extra
marks compared to the venerable, lovely, flatter and much easier to edit
Key: value format. The METADATA file needs to represent Name, Version, and
Requirements and the rest is fluff that no one will ever use. It's very
On Tue, Feb 26, 2013 at 12:38 AM, Daniel Holth dho...@gmail.com wrote:
I'm probably the only one but I'm not a fan of JSON with all the extra
marks compared to the venerable, lovely, flatter and much easier to edit
Key: value format.
I don't really care that much about human readability of
On Mon, Feb 25, 2013 at 9:54 AM, Nick Coghlan ncogh...@gmail.com wrote:
On Tue, Feb 26, 2013 at 12:38 AM, Daniel Holth dho...@gmail.com wrote:
I'm probably the only one but I'm not a fan of JSON with all the extra
marks compared to the venerable, lovely, flatter and much easier to edit
On Tue, Feb 26, 2013 at 12:59 AM, Daniel Holth dho...@gmail.com wrote:
On Mon, Feb 25, 2013 at 9:54 AM, Nick Coghlan ncogh...@gmail.com wrote:
On Tue, Feb 26, 2013 at 12:38 AM, Daniel Holth dho...@gmail.com wrote:
I'm probably the only one but I'm not a fan of JSON with all the extra
marks
On Tue, Feb 26, 2013 at 1:29 AM, Daniel Holth dho...@gmail.com wrote:
Well this is a rabbit hole. setup.cfg is what you get when the metadata
devolves into the arguments passed to setup(). Perhaps that is the real
reason I don't like JSON that much; the temptation would be to make it
nothing
Nick Coghlan ncoghlan at gmail.com writes:
The other area where I think such an embedded JSON approach could
work is coming up with a clean format for an Entry-Points field.
Specifically, I am thinking of proposing the setuptools.setup
inspired:
Entry-Points: {
I can accept a rename but there is no way to avoid having 2 names not 1 new
name for the feature.
We go halfway now. The next version can go any other way.
On Feb 25, 2013 12:23 PM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Nick Coghlan ncoghlan at gmail.com writes:
The other area where I
Daniel Holth dholth at gmail.com writes:
I can accept a rename but there is no way to avoid having 2 names not 1 new
name for the feature.
We go halfway now. The next version can go any other way.
Just to be clear, the naming of exports vs. entry points was not the main
thrust of my point -
Daniel Holth dholth at gmail.com writes:
We all must realize that incremental improvements are not harmful. Delay is
harmful; there has been no obvious way to make a Python package this decade
based on the idea that something better might be just around the corner or that
the current way will be
All I'm trying to say is do not add anything else to pep 426. There will be
other versions. This version can be consumed by distutils as of last July.
Daniel Holth dholth at gmail.com writes:
We all must realize that incremental improvements are not harmful. Delay
is
harmful; there has been no
by which I mean distribute
On Feb 25, 2013 5:55 PM, Daniel Holth dho...@gmail.com wrote:
All I'm trying to say is do not add anything else to pep 426. There will
be other versions. This version can be consumed by distutils as of last
July.
Daniel Holth dholth at gmail.com writes:
We all
12 matches
Mail list logo
