<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
On 05/10/2016 08:39 PM, Brett Cannon wrote:<br>
<blockquote type="cite">
<pre style="line-height:normal;word-wrap:break-word;white-space:pre-wrap">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).</pre>
</blockquote>
<br>
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<b>package</b>.yaml".<br>
<br>
It seems like the term "package", while possibly running into the
the "conflation issue", is a pretty solid term to build on. <br>
<ul>
<li>Python <b>Packaging</b> Authority (PyPA)<br>
</li>
<li><a class="moz-txt-link-freetext" href="http://python">http://python</a>-<b>packaging</b>-user-guide.readthedocs.io/en/latest/</li>
<li><a class="moz-txt-link-freetext" href="http://the-hitchhikers-guide-to">http://the-hitchhikers-guide-to</a>-<b>packaging</b>.readthedocs.io/en/latest/introduction.html<br>
</li>
<li>docs.python-guide.org/en/latest/shipping/<b>packaging</b>/</li>
<li>Top-level [<b>package</b>] namespace for the pep</li>
<li>From the PEP "This PEP specifies how Python software<b>
packages</b> should specify their build dependencies"</li>
<li>"As of March 2013, the Python <b>packaging</b> ecosystem is
currently in a rather
confusing state." [1]<br>
</li>
</ul>
<p>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. <br>
</p>
<p>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". <br>
</p>
<p>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.<br>
</p>
<p>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.<br>
</p>
<p>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. ;) <br>
</p>
<p>Thanks.<br>
</p>
<p>[1]
<a class="moz-txt-link-freetext" href="http://python-notes.curiousefficiency.org/en/latest/pep_ideas/core_packaging_api.html">http://python-notes.curiousefficiency.org/en/latest/pep_ideas/core_packaging_api.html</a></p>
<div class="moz-signature"><br>
<b>Randy Syring</b><br>
<small>Husband | Father | Redeemed Sinner</small><br>
<br>
<i><small>"For what does it profit a man to gain the whole world<br>
and forfeit his soul?" (Mark 8:36 ESV)</small></i></div>
</body>
</html>