distlib updated - comments sought
I've updated distlib as follows: 1. I've added support for the equivalent of "pkg_resources.resource_filename" for returning a true filesystem path for a resource. I've added info about this in the "Distlib's design" document, though the reference API has not been fully updated - I thought I'd see if there was any feedback about the approach I've used. Code and tests have been added, though. 2. I've added the PyPI client code from distutils2 in distlib.pypi. I only tweaked it a little to run under 2.x and 3.x from a single code base, ensuring that all the tests passed. I hope to update it with better support for finding archives not hosted on PyPI, using hints. I'm also considering the following changes, which I'd like some feedback on: * Merging the distlib.depgraph package into the distlib.database package, as they are fairly interlinked (e.g. adding requires() and required_by() methods to Distribution). * Removing depgraph.main() and its test, because I don't think it belongs in the library layer, but is better implemented as a utility script. Please let me have your comments. Regards, Vinay Sajip
On Thu, Oct 4, 2012 at 6:28 PM, Vinay Sajip
I've updated distlib as follows:
1. I've added support for the equivalent of "pkg_resources.resource_filename" for returning a true filesystem path for a resource. I've added info about this in the "Distlib's design" document, though the reference API has not been fully updated - I thought I'd see if there was any feedback about the approach I've used. Code and tests have been added, though.
:-) I still like the "mimic os.listdir but with an additional package argument" API because it has fewer parts. Is there a reason why we can't just fix pkgutil? It is probably much easier to do it in distlib. https://bitbucket.org/dholth/distlib2/src/tip/_distlib2/resources.py implements the distlib resources API using pkg_resources as the implementation. Check out how neat apipkg is in https://bitbucket.org/dholth/distlib2/src/tip/distlib/__init__.py. distlib2 does yet not implement any of the other distlib APIs.
2. I've added the PyPI client code from distutils2 in distlib.pypi. I only tweaked it a little to run under 2.x and 3.x from a single code base, ensuring that all the tests passed. I hope to update it with better support for finding archives not hosted on PyPI, using hints.
+0
I'm also considering the following changes, which I'd like some feedback on:
* Merging the distlib.depgraph package into the distlib.database package, as they are fairly interlinked (e.g. adding requires() and required_by() methods to Distribution).
+1 obviously since I asked
* Removing depgraph.main() and its test, because I don't think it belongs in the library layer, but is better implemented as a utility script.
+1 an installer probably only needs the toposort of the dependency graph
Daniel Holth
I still like the "mimic os.listdir but with an additional package argument" API because it has fewer parts. Is there a reason why we can't just fix pkgutil? It is probably much easier to do it in distlib.
Sorry, I didn't get what you meant in the above. Please clarify. Thanks for the feedback. Regards, Vinay Sajip
I mean should there be a pkgutil.pkg_listdir, etc. to accompany pkgutil.get_data
Daniel Holth
On Oct 5, 2012, at 5:32 AM, Vinay Sajip
Daniel Holth
writes: I still like the "mimic os.listdir but with an additional package argument" API because it has fewer parts. Is there a reason why we can't just fix pkgutil? It is probably much easier to do it in distlib.
Sorry, I didn't get what you meant in the above. Please clarify.
Thanks for the feedback.
Regards,
Vinay Sajip
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
On 10/5/12 12:28 AM, Vinay Sajip wrote:
I've updated distlib as follows:
1. I've added support for the equivalent of "pkg_resources.resource_filename" for returning a true filesystem path for a resource. I've added info about this in the "Distlib's design" document, though the reference API has not been fully updated - I thought I'd see if there was any feedback about the approach I've used. Code and tests have been added, though.
2. I've added the PyPI client code from distutils2 in distlib.pypi. I only tweaked it a little to run under 2.x and 3.x from a single code base, ensuring that all the tests passed. I hope to update it with better support for finding archives not hosted on PyPI, using hints.
I'm also considering the following changes, which I'd like some feedback on:
* Merging the distlib.depgraph package into the distlib.database package, as they are fairly interlinked (e.g. adding requires() and required_by() methods to Distribution).
* Removing depgraph.main() and its test, because I don't think it belongs in the library layer, but is better implemented as a utility script. I like the idea of having a main section to play with the tools, people can invoke with -m
I don't think its a bad idea to have it in each module, like what Python does for SimpleHTTPServer or json.tools stuff we could have: - a manifest reader with various options - displaying a dependency graph - querying some stuff at PyPI.. etc..
Please let me have your comments.
Regards,
Vinay Sajip
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Tarek Ziadé
I like the idea of having a main section to play with the tools, people can invoke with -m
I don't think its a bad idea to have it in each module, like what Python does for SimpleHTTPServer or json.tools
I've no problem with having a "if __name == '__main__'" section, but I don't think it should need to be unit tested, or form part of the contract of the module. For example, the depgraph.main() test as it stands is dependent on whatever happens to be on sys.path on the machine running the test, possibly leading to results unreproducible by different people. For example, on my machine, the test originally failed because of version numbers of legacy distributions on sys.path, which didn't meet PEP 386 standards and led to exceptions being raised in depgraph.main(). I commented out the "raise" and replaced it with a "continue", and the test then passed. Regards, Vinay Sajip
On 10/5/12 12:19 PM, Vinay Sajip wrote:
Tarek Ziadé
writes: I like the idea of having a main section to play with the tools, people can invoke with -m
I don't think its a bad idea to have it in each module, like what Python does for SimpleHTTPServer or json.tools
I've no problem with having a "if __name == '__main__'" section, but I don't think it should need to be unit tested, or form part of the contract of the module. oh yeah - I don't care about this part :)
participants (3)
-
Daniel Holth -
Tarek Ziadé -
Vinay Sajip