Issue 12302: packaging test command needs access to .dist-info (original) (raw)

Issue12302

Created on 2011-06-09 22:57 by michael.mulich, last changed 2022-04-11 14:57 by admin. This issue is now closed.

Messages (5)
msg138032 - (view)	Author: Michael Mulich (michael.mulich) *	Date: 2011-06-09 22:57
A package's metadata (dist-info) should be available to it while running the test command (pysetup run test)? The use case: I've written a test for a function that is supposed to find the default configuration or one provided in a users local area (or {userbase} as sysconfig puts it). As part of the test, I'm ensuring that the forcibly found default config is loaded correctly. The function that finds the configuration uses sysconfig paths (sysconfig.get_paths) which rely on the packaging database (PEP 376 API now in packaging.database). To find the default config, or resource in packaging terms, I'm using the packaging.database.get_file_path, which requires the distribution metadata (dist-info) be available within the Python path, because it must lookup the RESOURCES file. I've started work, in my local clone. We lack a unittest for this case. I'll be writing it some time within the next few days. I'd like to know where this RESOURCES file came from? I don't recall, nor see mention of it in PEP 376. I would also have expected to find something in packaging.command.install_distinfo command related to this file. The install_distinfo command is lacking this logic. I'll add it after the first half of this case working.
msg138037 - (view)	Author: Michael Mulich (michael.mulich) *	Date: 2011-06-09 23:14
The RESOURCES implement in install_distinfo command should probably be a separate case, no?
msg138092 - (view)	Author: Éric Araujo (eric.araujo) *	Date: 2011-06-10 16:01
> while running the test command (pysetup run test)? Yes, that’s the correct invocation. > The use case: [...] I agree with the need. I’ve added a dep on the bug requesting the addition of a build_distinfo command; once it is done, this bug will be solved, since test runs build and places the build lib in sys.path (which also enables running tests on code converted by 2to3 at build time). > The function that finds the configuration uses sysconfig paths > (sysconfig.get_paths) which rely on the packaging database (PEP 376 > API now in packaging.database). sysconfig does rely on packaging. > To find the default config, or resource in packaging terms, I'm using > the packaging.database.get_file_path, which requires the distribution > metadata (dist-info) be available within the Python path This however is correct. > I'd like to know where this RESOURCES file came from? I don't recall, > nor see mention of it in PEP 376. This is the implementation of the discussion originally started in https://bitbucket.org/tarek/distutils2/src/6c3d67ed3adb/docs/design/wiki.rst I think it was originally intended to be a new PEP, but during distutils2 sprints it was directly coded. Resources replace data_files. > I would also have expected to find something in > packaging.command.install_distinfo command related to this file. It’s subtle; grep for RESOURCES and you’ll find it. The list of files is built by install_data and written by install_distinfo. If you want to learn more about this code, go to a distutils2 repo and look at the log.
msg138094 - (view)	Author: Éric Araujo (eric.araujo) *	Date: 2011-06-10 16:04
Typo: sysconfig does *not* rely on packaging.
msg140852 - (view)	Author: Éric Araujo (eric.araujo) *	Date: 2011-07-22 01:10
For #8668 (develop command), higery has written code that reuses install_distinfo to create the dist-info dir in the build dir. It requires #12344, which I will commit when Thomas has time to finish his patch. We also need to make install_distinfo more flexible: For example, on #12279 we discussed about the RECORD file, which should be empty when created by the test command (nothing is installed), and we mentioned RESOURCES, which should probably be created, with relative paths. (The resources API is intended to work with zero config in a source checkout or unpacked tarball, even though it currently doesn’t, but given that test runs in the build dir, we’re not in the source dir anymore, so RESOURCES should probably be written.)