Creating distribution for Python *module*, not package
Hello,
I would like to create a PyPIable packaged disribution for a single-file python module (say, foo.py). How to achieve that? There doesn't seem to be "modules" param to setup() (as a mirror of "packages" param).
Thanks, Paul mailto:pmiscml@gmail.com
Hello,
On Tue, 1 Apr 2014 22:25:09 +0300 Paul Sokolovsky pmiscml@gmail.com wrote:
Hello,
I would like to create a PyPIable packaged disribution for a single-file python module (say, foo.py). How to achieve that? There doesn't seem to be "modules" param to setup() (as a mirror of "packages" param).
Ah, pure magic: google it, search stackoverflow - find nothing. Post a question to mailing list, and next step find the answer - the param is called "py_modules".
Let's analyze: I would expect a complete reference of setup() params on https://pythonhosted.org/setuptools/ , and/or explicit and very visible mentioning that setuptools is extension to distutils and its docs should be read first.
Instead I get:
Confusing TOC, first entry is called "Roadmap", which doesn't provide any roadmap, but instead status. Next one "Supporting both Python 2 and Python 3 with Setuptools" - oh, sure that's first thing I want to know about setuptools. Or maybe no, first thing I want to know what the heck it is. So, the section with which manual should start, "Building and Distributing Packages with Setuptools" is #4 in TOC, no wonder it takes a while for people to get to it. Searching for "py_modules" returns 0 hits.
And kind suggestion for packaging tutorials writers - please start from the start, by describing how to package a *module*, there's no need to force package bloat on everyone. And the latter is exactly what 3 google-top tutorials I read did.
Keep up the great work!
Yeah, setuptools is a bw-compat wrapper around distutils, so it tends to only document its new features. This approach to documentation makes it very difficult to understand for newcomers that are not familiar with distutils. Especially now that setuptools is the de facto standard that everyone is learning how to use.
https://docs.python.org/2/distutils/examples.html#pure-python-distribution-b...
On Tue, Apr 1, 2014 at 2:46 PM, Paul Sokolovsky pmiscml@gmail.com wrote:
Hello,
On Tue, 1 Apr 2014 22:25:09 +0300 Paul Sokolovsky pmiscml@gmail.com wrote:
Hello,
I would like to create a PyPIable packaged disribution for a single-file python module (say, foo.py). How to achieve that? There doesn't seem to be "modules" param to setup() (as a mirror of "packages" param).
Ah, pure magic: google it, search stackoverflow - find nothing. Post a question to mailing list, and next step find the answer - the param is called "py_modules".
Let's analyze: I would expect a complete reference of setup() params on https://pythonhosted.org/setuptools/ , and/or explicit and very visible mentioning that setuptools is extension to distutils and its docs should be read first.
Instead I get:
Confusing TOC, first entry is called "Roadmap", which doesn't provide any roadmap, but instead status. Next one "Supporting both Python 2 and Python 3 with Setuptools" - oh, sure that's first thing I want to know about setuptools. Or maybe no, first thing I want to know what the heck it is. So, the section with which manual should start, "Building and Distributing Packages with Setuptools" is #4 in TOC, no wonder it takes a while for people to get to it. Searching for "py_modules" returns 0 hits.
And kind suggestion for packaging tutorials writers - please start from the start, by describing how to package a *module*, there's no need to force package bloat on everyone. And the latter is exactly what 3 google-top tutorials I read did.
Keep up the great work!
-- Best regards, Paul mailto:pmiscml@gmail.com _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
On 1 April 2014 21:16, Michael Merickel mmericke@gmail.com wrote:
Yeah, setuptools is a bw-compat wrapper around distutils, so it tends to only document its new features. This approach to documentation makes it very difficult to understand for newcomers that are not familiar with distutils. Especially now that setuptools is the de facto standard that everyone is learning how to use.
Agreed. The packaging documentation grew piecemeal over time, staring from a basis of the distutils documentation which was itself pretty incomprehensible. We're working on a new iteration of the packaging documentation at https://python-packaging-user-guide.readthedocs.org/en/latest/ but to be honest, it's very easy to take for granted a lot of basics, simply because the people doing the writing are too close to the packaging ecosystem. For example, I don't think anyone considered documenting a single Python module as mentioned by the OP (it's usually the case that your needs very soon grow to the point where a single module isn't enough, but that's not a reason to not cover it - just a possible reason why we never thought of it).
We'd be very grateful for any contributions to the packaging user guide, either in the form of pull requests or even just issues on the tracker pointing at things we should cover (or should cover better).
Paul
On 2 Apr 2014 06:41, "Paul Moore" p.f.moore@gmail.com wrote:
On 1 April 2014 21:16, Michael Merickel mmericke@gmail.com wrote:
Yeah, setuptools is a bw-compat wrapper around distutils, so it tends to only document its new features. This approach to documentation makes it
very
difficult to understand for newcomers that are not familiar with
distutils.
Especially now that setuptools is the de facto standard that everyone is learning how to use.
Agreed. The packaging documentation grew piecemeal over time, staring from a basis of the distutils documentation which was itself pretty incomprehensible. We're working on a new iteration of the packaging documentation at https://python-packaging-user-guide.readthedocs.org/en/latest/ but to be honest, it's very easy to take for granted a lot of basics, simply because the people doing the writing are too close to the packaging ecosystem.
Marcus has also been doing a lot of work trying to coordinate consistency updates to the stdlib, pip, virtualenv and setuptools docs to get them in sync with each other and bring them into line with the new overall user guide (Now available as packaging.python.org, btw).
The fact several aspects of the setuptools docs assume readers are already experienced distutils users just happens to be one of the harder problems to resolve in that space, as fixing it requires extracting the relevant info from the 15+ year old distutils docs and combining it with the already complicated setuptools docs :P
(It's also influenced by the fact that more of the PyPA's focus for the past year has been on cleaning up the installation side of the story. As that has now reached a better state with the release of Python 3.4 and its bundled pip bootstrapping mechanism, I expect we'll see more movement on the build side of things this year)
Cheers, Nick.
For example, I don't think anyone considered documenting a single Python module as mentioned by the OP (it's usually the case that your needs very soon grow to the point where a single module isn't enough, but that's not a reason to not cover it - just a possible reason why we never thought of it).
We'd be very grateful for any contributions to the packaging user guide, either in the form of pull requests or even just issues on the tracker pointing at things we should cover (or should cover better).
Paul _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
On Apr 1, 2014, at 5:24 PM, Nick Coghlan ncoghlan@gmail.com wrote:
On 2 Apr 2014 06:41, "Paul Moore" p.f.moore@gmail.com wrote:
On 1 April 2014 21:16, Michael Merickel mmericke@gmail.com wrote:
Yeah, setuptools is a bw-compat wrapper around distutils, so it tends to only document its new features. This approach to documentation makes it very difficult to understand for newcomers that are not familiar with distutils. Especially now that setuptools is the de facto standard that everyone is learning how to use.
Agreed. The packaging documentation grew piecemeal over time, staring from a basis of the distutils documentation which was itself pretty incomprehensible. We're working on a new iteration of the packaging documentation at https://python-packaging-user-guide.readthedocs.org/en/latest/ but to be honest, it's very easy to take for granted a lot of basics, simply because the people doing the writing are too close to the packaging ecosystem.
Marcus has also been doing a lot of work trying to coordinate consistency updates to the stdlib, pip, virtualenv and setuptools docs to get them in sync with each other and bring them into line with the new overall user guide (Now available as packaging.python.org, btw).
The fact several aspects of the setuptools docs assume readers are already experienced distutils users just happens to be one of the harder problems to resolve in that space, as fixing it requires extracting the relevant info from the 15+ year old distutils docs and combining it with the already complicated setuptools docs :P
(It's also influenced by the fact that more of the PyPA's focus for the past year has been on cleaning up the installation side of the story. As that has now reached a better state with the release of Python 3.4 and its bundled pip bootstrapping mechanism, I expect we'll see more movement on the build side of things this year)
Cheers, Nick.
For example, I don't think anyone considered documenting a single Python module as mentioned by the OP (it's usually the case that your needs very soon grow to the point where a single module isn't enough, but that's not a reason to not cover it - just a possible reason why we never thought of it).
We'd be very grateful for any contributions to the packaging user guide, either in the form of pull requests or even just issues on the tracker pointing at things we should cover (or should cover better).
Paul _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
I was idly considering a setup.py.packaging.python.org or setup.py.python.org earlier that was something like http://package.json.nodejitsu.com/
----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
participants (5)
-
Donald Stufft -
Michael Merickel -
Nick Coghlan -
Paul Moore -
Paul Sokolovsky