>> I think you are misunderstanding. The infrastructure will *not* depend >> on the old formats. Instead, packaging that have that information will >> provide it, packages that don't will not. The infrastructure is entirely >> agnostic on whether the data is available or not. In particular, it will >> not try to interpret the data in any way. >> > No, not at all. If tools *use* the information (and if they don't then > what is the point?) then packages that want to be compatible with those > tools will have to provide this information. Not true. Tools could/should also support PEP 345 data, and then they can support either kind of package. > By providing information in this format PyPI will (like it or not) be > blessing this format as the 'standard' way of providing this > information. By that definition, *both* formats are "blessed". The PEP 345 data is already blessed. Depending on the definition of "providing", the egg-info data are also already "provided", ever since PyPI started accepting egg files. >> I don't think this can well happen. In most known use cases, the tools >> could support both forms of metadata. > Well, a) I would like to see that demonstrated The tool in question is tl.eggdepend. It can easily support both kinds of metadata. > and b) having one > standard is *far* preferable and having the distutils2 format be that > standard is also far preferable. Please wait a bit (or start on > supporting the distutils2 metadata format now). The latter is already the case: the distutils2 metadata *is* supported *now*. It's just that no package is using it (except for pep345demo). As for a bit: how long exactly? >> That's really sad. So people will have to wait a few years to >> efficiently implement tools that they could implement today. > > Why a few years? Because it will take that long until a significant number of packages will use distutils 2. People still use very old versions of packaging tools (e.g. the ones that come with Debian); it will just take time to get the new tools and API adopted. Regards, Martin
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4