Me too. YAML is *so much* more widely used, and the complicated edge cases
can simply be ignored for this requirement.
Maybe it's just because I've never heard of whatever improper behavior the
author engaged in, but I don't think a data format needs to answer to the
actions of its creator(s). If
On 2017-08-25 16:16:39 -0700 (-0700), Nathaniel Smith wrote:
[...]
> I've wondered if we should fork it, rename it "the obvious minimal
> language", and release our own 1.0.
And make it a toggleable option to configparser? ;)
The basic format is pretty similar, granted TOML has a lot more
On Fri, Aug 25, 2017 at 5:46 PM, xoviat wrote:
> I personally do not understand the aversion to YAML. I mean yes, the
> specification is more complicated, but it's also more popular and the YAML
> files will not be complex enough for a C library to help that much. And
> since
I personally do not understand the aversion to YAML. I mean yes, the
specification is more complicated, but it's also more popular and the YAML
files will not be complex enough for a C library to help that much. And
since it's more popular, people might even prefer specifying package
metadata in a
On Fri, Aug 25, 2017 at 1:00 PM, Jeremy Stanley wrote:
> (The
> community around it is sensitive to gender diversity issues and
> wants to avoid acquiring more of a "brogrammer" image, so some of us
> worry that any conspicuous TOML files checked into revision control
>
On 2017-08-25 14:00:25 +0100 (+0100), Paul Moore wrote:
[...]
> I'm not that familiar with those tools, but if they enable that
> sort of use then that's great. I did get the impression that they
> were for more complex/specialised use cases, though, whereas flit
> (with PEP 517) is much more
On 25 August 2017 at 12:14, Jeremy Stanley wrote:
> On 2017-08-25 10:50:11 +0100 (+0100), Paul Moore wrote:
> [...]
>> once PEP 517 is implemented and as flit gains popularity, I fully
>> expect more and more projects to use a static data structure for
>> their metadata
On 2017-08-25 07:37:23 -0500 (-0500), Ian Stapleton Cordasco wrote:
> Except that OpenStack frequently rejects outside use cases as I
> learned as an OpenStack developer who tried to improve PBR. Sadly
> it will never be seen as a global solution as long as that
> continues
Many projects
It's important to realize that build is a Turing-complete activity. We
write programs to build programs. Where setup.py gets in trouble is by
making both the metadata and the build script the same thing, making it
harder to reason about that metadata. That is why we are working towards
being able
Except that OpenStack frequently rejects outside use cases as I learned as
an OpenStack developer who tried to improve PBR. Sadly it will never be
seen as a global solution as long as that continues
On Aug 25, 2017 6:32 AM, "Jeremy Stanley" wrote:
> On 2017-08-25 10:50:11
On 2017-08-25 10:50:11 +0100 (+0100), Paul Moore wrote:
[...]
> once PEP 517 is implemented and as flit gains popularity, I fully
> expect more and more projects to use a static data structure for
> their metadata (flit.ini, specifically).
This has also been possible for years already using
On 25 August 2017 at 09:36, Thomas Güttler wrote:
> The setup.py of numpy looks big and complicated:
> https://github.com/numpy/numpy/blob/master/setup.py
>
> I guess there are even more complicated setup.py files.
>
> Do you think it will be possible in the future
Hi Thomas!
Have you seen Pipfile? It's something along those lines - a declarative
specification of project data. :)
github.com/pypa/pipfile
Regards,
Pradyun Gedam
On Fri, Aug 25, 2017, 14:12 Thomas Güttler
wrote:
> The setup.py of numpy looks big and
The setup.py of numpy looks big and complicated:
https://github.com/numpy/numpy/blob/master/setup.py
I guess there are even more complicated setup.py files.
Do you think it will be possible in the future to make setup.py conditionless (no "if",
no "else", no function calls)?
I mean that the
14 matches
Mail list logo