This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Remove required metadata warnings for sdist
Type: enhancement Stage: resolved
Components: Distutils Versions: Python 3.2, Python 2.7
process
Status: closed Resolution: wont fix
Dependencies: Superseder:
Assigned To: tarek Nosy List: eric.araujo, francismb, michael.foord, tarek
Priority: normal Keywords:

Created on 2010-01-17 17:13 by michael.foord, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Messages (4)
msg97957 - (view) Author: Michael Foord (michael.foord) * (Python committer) Date: 2010-01-17 17:13
When building releases with sdist (and other distribution building options) missing metadata should not cause warnings. For public projects this is useful (i.e. projects uploaded to PyPI), but not for internally built distributions. (If a distribution is not public then why should it have a URL for example.)
msg119369 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2010-10-22 08:54
I don’t think warnings should be removed, at least not by default.  They’re warnings, not errors, which is IMO a nice compromise between accepting anything and requiring that rules be followed.  We could add an option like --no-warnings in distutils2, but I’m worried people could just disable it globally instead of fixing the actual problems.  I’m inclined to reject this report.  Tarek, opinion?

Since the warnings go to stderr, you can suppress them with shell redirection, although I wouldn’t advise that since you could miss unrelated warnings or errors.  Does that cover your need?

*musing* Maybe we could revamp the required fields.  Name and version are required by various distutils[2] and pkgutil APIs, so not setting them will screw up queries or uninstallation for example.  We could make distutils2 fail when they’re not present.  But then, why not fail if a distribution to be installed has the same name+version that an already present distribution?  What I’m saying is that it’s better to do no checks than incomplete checks, and this is the realm of a distribution manager, not the underlying library, but then again, distutils2 provides a simple distribution manager too, so I’m not sure this should be in or out of it, and at which level (lib/command/manager).

(Removing Terry from nosy at his request in private email.)
msg228454 - (view) Author: Francis MB (francismb) * Date: 2014-10-04 13:09
AFAICS, this is an enhancement issue for the currently in maintenance branches 2.7 and 3.2. 

Does this still applies to 3.5? (otherwise this issue should/could be closed).
msg379356 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2020-10-22 21:27
Distutils won’t be changed at this point in time, this request should go to setuptools.
History
Date User Action Args
2022-04-11 14:56:56adminsetgithub: 51975
2020-10-22 21:27:35eric.araujosetstatus: open -> closed
resolution: wont fix
messages: + msg379356

stage: resolved
2014-10-04 13:09:25francismbsettype: enhancement

messages: + msg228454
nosy: + francismb
2010-10-22 08:54:25eric.araujosetmessages: - msg113019
2010-10-22 08:54:19eric.araujosetnosy: + eric.araujo, - terry.reedy
messages: + msg119369
2010-08-05 19:12:30terry.reedysetnosy: + terry.reedy
messages: + msg113019
2010-01-17 17:13:15michael.foordcreate