[Distutils] PEP for specifying build dependencies

[Randy Syring]

  On 05/10/2016 08:39 PM, Brett Cannon wrote:
> The build dependencies will be stored in a file named
> ``pyproject.toml``
>
> [...snip...]
>
> A top-level ``[package]`` table will represent details specific to the
> package that the project contains.
>
> [...snip...]
>
> Rejected Ideas
> ==============
>
> pypackage.toml & pypackaging.toml
>    Name conflation of what a "package" is (project versus namespace).

I know this is in the rejected ideas, but I'd like to point out that 
there is an inconsistency here that bothers me.  If the top-level 
namespace in the file is going to be "package" then it makes sense to me 
that the file would also be named "py*package*.yaml".

It seems like the term "package", while possibly running into the the 
"conflation issue", is a pretty solid term to build on.

  * Python *Packaging* Authority (PyPA)
  * http://python-*packaging*-user-guide.readthedocs.io/en/latest/
  * http://the-hitchhikers-guide-to-*packaging*.readthedocs.io/en/latest/introduction.html
  * docs.python-guide.org/en/latest/shipping/*packaging*/
  * Top-level [*package*] namespace for the pep
  *  From the PEP "This PEP specifies how Python software*packages*
    should specify their build dependencies"
  * "As of March 2013, the Python *packaging* ecosystem is currently in
    a rather confusing state." [1]

Given the proliferation of the term "package" in describing exactly what 
this file is about, I'd really like to see the file name reconsidered to 
be  "pypackag[e|ing].toml".  Python "packaging", at least in the 
discussions I follow and am involved is, is becoming _the term_ to refer 
to this part of the Python ecosystem.

IMO, the term "project" is more ambiguous, it could possibly refer to a 
lot of things.  So, IMO, if you are just weighing the two terms on 
possibility for misunderstanding, "packaging" may get docked a point for 
being conflated with a python top-level module namespace but project 
should equally get docked a point for just being too generic AND another 
point for not matching the top-level config namespace of the file.  If 
you add in the fact that "packaging" is used frequently in the Python 
ecosystem now to refer to the process of bundling up and installing a 
python source tree, that's like +5 for "pypackag[e|ing].toml".

And, if the case of conflation still feels strong, then surly using 
"pypackaging.toml" would have to remove most of the confusion.  
Although, I'd prefer "pypackage.toml" myself.

I suppose, if its possible the file would ever have a different 
top-level config namespace other than "package" so that information 
related to non-packaging issues could possible end up here (like maybe 
tox or flake8 starting to read config from here instead of from 
setup.cfg) then I don't think I'd feel as strongly about 
"pyproject.toml" being too generic.

Although, we could be a bit cagy and make a play on "crate" by using a 
synonym "carton" (carton.toml, pycarton.toml) which, interestingly, 
sometimes hold eggs.  ;)

Thanks.

[1] 
http://python-notes.curiousefficiency.org/en/latest/pep_ideas/core_packaging_api.html


*Randy Syring*
Husband | Father | Redeemed Sinner

/"For what does it profit a man to gain the whole world
and forfeit his soul?" (Mark 8:36 ESV)/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20160510/6a86e675/attachment.html>