By Chris Barker via Discussions on Python.org at 14Apr2022 00:19:
This is a not-very-new thread, but I wanted to add my $0.02:
@cameron : thanks for working on this – It should be a great
contribution to the packaging world
My main note:
" The document aims to outline the flow involved in publishing a package, usually to PyPI."
I actually think this is a problem with the entire realm of pacakging documentiona – the emphasis on “publishing on PyPi”. But isn’t that what people want/need to do?
Well, that is why I used the term “usually”. I want to set out what has
to be achieved, with a nod of the head at the usual target because (a)
that is often the new packager’s primary objective and (b) because it
gives a mental model of “where” a package may be published.
I’m trying to paint a mental picture here, so that people know where the
pieces fit in that picture. The other docs specify how the various
pieces of string or twine or rope must be made; I’m aiming for the shape
of the frame.
Well, yes and not – yes, that’s important target group, but:
- There are many reasons to build and maintain packages that will
never be published on PyPi
Yes. Again, “usually” PyPI, particularly for the new packager.
I particularly do not want to complicate the overview with all the
possible ways one might want to package+publish something. That…
burgoening of possibilities is what makes the other docs so hard to
read. I’m after the flow, annotated with typical targets (PyPI) to
- The emphasis on publishing means that newbies tend to think they are “supposed” to do that – witness the plethora of half-baked unmaintained packages on PyPi
Well, perhaps. But if you’re not publishing (even to yourself, locally),
why would you need to package?
And if an overview makes it easier to fully bake and later maintain (by
releasing updates) a package through having a better conceptual grasp of
the framework, shouldn’t that help?
- I actually think the publishing part is the easy part – it’s the
building part that’s hard, particularly if you have to build C
extensions (with or without Cython). – and that gets kinda lost in the
To me it is the pair. Yes building is hard, not because it is hard, but
because it is hard to grasp.
Anyway – I’ll go read your page carefully now and comment there.
Cameron Simpson firstname.lastname@example.org