#pythonpackaging — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #pythonpackaging, aggregated by home.social.
-
@Armavica This capability ("default extras") doesn't exist yet, but I have definitely seen a proposal for it. I hope that gets accepted and implemented at some point.
Until then, if you wind up explaining this in your package's installation instructions and telling people they have to manually select one of the three extras, you certainly wouldn't be alone. Of course it'd be ideal if your package (or keras) also checks at runtime and give a useful error message if it doesn't find any of the three dependencies installed.
-
How uv got so fast: https://nesbitt.io/2025/12/26/how-uv-got-so-fast.html
"uv is fast because of what it doesn’t do, not because of what language it’s written in."
-
For those following along on this 'exciting' saga, I did, in fact, submit a PR. It has been merged and a new version of pypostal has been released. Another OSS success story.
https://github.com/openvenues/pypostal/pull/96 -
Didn't realize that homebrew finally packaged libpostal, that's awesome! Still can't use pypostal though because it has hard coded lib and include dirs that don't work with homebrew's /opt/homebrew/... prefix 😞
Also it still claims python 2 support 😬
I wonder if they'd be open to PRs…
-
🐍 pyOpenSci has helped 50+ Python packages get production-ready.
Now join founder @leahawasser for a 2-hour workshop to learn the same packaging practices we share in peer review.
📅 Nov 6 | 10 AM MST
🎟️ Early bird ends Oct 5 + scholarships available
🔗 bit.ly/PythonPackaging -
Join our hands-on #SciPy2025 workshop led by Leah Wasser, Inessa Pawson, Carol Willing & Tetsuo Koyama.
You’ll:
✅ Build your own Python package
✅ Learn best practices
✅ Publish to TestPyPI
✅ Get packaging resources + community supportNo installs needed—GitHub Codespaces works too!
📅 July 8, 8am–12pm PT
📍 Room 316, Greater Tacoma Convention CenterWorkshop info: https://www.pyopensci.org/events/pyopensci-scipy25-create-python-package-workshop.html
More SciPy events: https://www.pyopensci.org/blog/pyopensci-at-scipy-2025.html
-
Join our hands-on #SciPy2025 workshop led by Leah Wasser, Inessa Pawson, Carol Willing & Tetsuo Koyama.
You’ll:
✅ Build your own Python package
✅ Learn best practices
✅ Publish to TestPyPI
✅ Get packaging resources + community supportNo installs needed—GitHub Codespaces works too!
📅 July 8, 8am–12pm PT
📍 Room 316, Greater Tacoma Convention CenterWorkshop info: https://www.pyopensci.org/events/pyopensci-scipy25-create-python-package-workshop.html
More SciPy events: https://www.pyopensci.org/blog/pyopensci-at-scipy-2025.html
-
Join our hands-on #SciPy2025 workshop led by Leah Wasser, Inessa Pawson, Carol Willing & Tetsuo Koyama.
You’ll:
✅ Build your own Python package
✅ Learn best practices
✅ Publish to TestPyPI
✅ Get packaging resources + community supportNo installs needed—GitHub Codespaces works too!
📅 July 8, 8am–12pm PT
📍 Room 316, Greater Tacoma Convention CenterWorkshop info: https://www.pyopensci.org/events/pyopensci-scipy25-create-python-package-workshop.html
More SciPy events: https://www.pyopensci.org/blog/pyopensci-at-scipy-2025.html
-
Join our hands-on #SciPy2025 workshop led by Leah Wasser, Inessa Pawson, Carol Willing & Tetsuo Koyama.
You’ll:
✅ Build your own Python package
✅ Learn best practices
✅ Publish to TestPyPI
✅ Get packaging resources + community supportNo installs needed—GitHub Codespaces works too!
📅 July 8, 8am–12pm PT
📍 Room 316, Greater Tacoma Convention CenterWorkshop info: https://www.pyopensci.org/events/pyopensci-scipy25-create-python-package-workshop.html
More SciPy events: https://www.pyopensci.org/blog/pyopensci-at-scipy-2025.html
-
Join our hands-on #SciPy2025 workshop led by Leah Wasser, Inessa Pawson, Carol Willing & Tetsuo Koyama.
You’ll:
✅ Build your own Python package
✅ Learn best practices
✅ Publish to TestPyPI
✅ Get packaging resources + community supportNo installs needed—GitHub Codespaces works too!
📅 July 8, 8am–12pm PT
📍 Room 316, Greater Tacoma Convention CenterWorkshop info: https://www.pyopensci.org/events/pyopensci-scipy25-create-python-package-workshop.html
More SciPy events: https://www.pyopensci.org/blog/pyopensci-at-scipy-2025.html
-
Learn the basics of creating a Python package!
Learn about package structure, the pyproject.toml file (metadata) adding docstrings and code and using your package.🎥 Watch now! https://youtu.be/XAq-HnPU4XM
#Python #pythonpackaging #OpenSource #openscience -
🚨 Quick Ways to Secure Your Python PyPI Publishing Workflow! 🚨
🔒 Want to keep your package safe? Follow these 3 key security steps:
✅ Use GitHub Environments to restrict your publishing workflows
✅ Set up PyPI Trusted Publisher instead of API tokens
✅ Scan your workflows with zizmor (on PyPI) to identify security flawsRead more in our latest blog post:
🔗 https://www.pyopensci.org/blog/python-packaging-security-publish-pypi.html -
getting back into Python is weird because like every time I do there's a new fresh hotness to theoretically end all hotnessess re: package installation
and then the next time I get back in people are like, "that was such horseshit, this is the thing"
"wheel is bad, but poetry: so good!"
"poetry is shit, something something else is good (I dunno I kinda don't remember the name for this one)"
"we don't need that old one, we have WHEEL!"
motherfuckers
(yes, these are real things)
#techPosting #pythonLang #pythonPackaging -
getting back into Python is weird because like every time I do there's a new fresh hotness to theoretically end all hotnessess re: package installation
and then the next time I get back in people are like, "that was such horseshit, this is the thing"
"wheel is bad, but poetry: so good!"
"poetry is shit, something something else is good (I dunno I kinda don't remember the name for this one)"
"we don't need that old one, we have WHEEL!"
motherfuckers
(yes, these are real things)
#techPosting #pythonLang #pythonPackaging -
getting back into Python is weird because like every time I do there's a new fresh hotness to theoretically end all hotnessess re: package installation
and then the next time I get back in people are like, "that was such horseshit, this is the thing"
"wheel is bad, but poetry: so good!"
"poetry is shit, something something else is good (I dunno I kinda don't remember the name for this one)"
"we don't need that old one, we have WHEEL!"
motherfuckers
(yes, these are real things)
#techPosting #pythonLang #pythonPackaging -
getting back into Python is weird because like every time I do there's a new fresh hotness to theoretically end all hotnessess re: package installation
and then the next time I get back in people are like, "that was such horseshit, this is the thing"
"wheel is bad, but poetry: so good!"
"poetry is shit, something something else is good (I dunno I kinda don't remember the name for this one)"
"we don't need that old one, we have WHEEL!"
motherfuckers
(yes, these are real things)
#techPosting #pythonLang #pythonPackaging -
getting back into Python is weird because like every time I do there's a new fresh hotness to theoretically end all hotnessess re: package installation
and then the next time I get back in people are like, "that was such horseshit, this is the thing"
"wheel is bad, but poetry: so good!"
"poetry is shit, something something else is good (I dunno I kinda don't remember the name for this one)"
"we don't need that old one, we have WHEEL!"
motherfuckers
(yes, these are real things)
#techPosting #pythonLang #pythonPackaging -
🥳 Registration for the pyOpenSci Open Science Fall Festival is LIVE! Join us for five incredible days, including:
💜 Amazing keynotes
🛠️ Hands-on workshops, covering Python Packaging, Quarto, and Great Tables
📚 Office hours, a chance to get extra help, info, and clarification on workshop topicsWe can't wait to see you there!
#Python #OpenSource #OpenScience #pyOSFallFestival #Quarto #GreatTables #PythonPackaging
-
🥳 Registration for the pyOpenSci Open Science Fall Festival is LIVE! Join us for five incredible days, including:
💜 Amazing keynotes
🛠️ Hands-on workshops, covering Python Packaging, Quarto, and Great Tables
📚 Office hours, a chance to get extra help, info, and clarification on workshop topicsWe can't wait to see you there!
#Python #OpenSource #OpenScience #pyOSFallFestival #Quarto #GreatTables #PythonPackaging
-
🥳 Registration for the pyOpenSci Open Science Fall Festival is LIVE! Join us for five incredible days, including:
💜 Amazing keynotes
🛠️ Hands-on workshops, covering Python Packaging, Quarto, and Great Tables
📚 Office hours, a chance to get extra help, info, and clarification on workshop topicsWe can't wait to see you there!
#Python #OpenSource #OpenScience #pyOSFallFestival #Quarto #GreatTables #PythonPackaging
-
🥳 Registration for the pyOpenSci Open Science Fall Festival is LIVE! Join us for five incredible days, including:
💜 Amazing keynotes
🛠️ Hands-on workshops, covering Python Packaging, Quarto, and Great Tables
📚 Office hours, a chance to get extra help, info, and clarification on workshop topicsWe can't wait to see you there!
#Python #OpenSource #OpenScience #pyOSFallFestival #Quarto #GreatTables #PythonPackaging
-
🥳 Registration for the pyOpenSci Open Science Fall Festival is LIVE! Join us for five incredible days, including:
💜 Amazing keynotes
🛠️ Hands-on workshops, covering Python Packaging, Quarto, and Great Tables
📚 Office hours, a chance to get extra help, info, and clarification on workshop topicsWe can't wait to see you there!
#Python #OpenSource #OpenScience #pyOSFallFestival #Quarto #GreatTables #PythonPackaging
-
Any other #Python developers working in restricted environments? I could use some help figuring out a process for building python packages which don't require many (or any) dependencies from #PyPI
https://stackoverflow.com/q/78974383/3070534
#Python3 #python_programming #PythonPackaging #programmingadvice
-
Any other #Python developers working in restricted environments? I could use some help figuring out a process for building python packages which don't require many (or any) dependencies from #PyPI
https://stackoverflow.com/q/78974383/3070534
#Python3 #python_programming #PythonPackaging #programmingadvice
-
Any other #Python developers working in restricted environments? I could use some help figuring out a process for building python packages which don't require many (or any) dependencies from #PyPI
https://stackoverflow.com/q/78974383/3070534
#Python3 #python_programming #PythonPackaging #programmingadvice
-
Any other #Python developers working in restricted environments? I could use some help figuring out a process for building python packages which don't require many (or any) dependencies from #PyPI
https://stackoverflow.com/q/78974383/3070534
#Python3 #python_programming #PythonPackaging #programmingadvice
-
Any other #Python developers working in restricted environments? I could use some help figuring out a process for building python packages which don't require many (or any) dependencies from #PyPI
https://stackoverflow.com/q/78974383/3070534
#Python3 #python_programming #PythonPackaging #programmingadvice
-
@fludiblu @Nevil A quick summary of the essentials: the standard way to distributed a Python package is as an archive file which follows a certain standard format (details don't matter here), allowing it to be installed by any pip-compatible installer. That means pip itself, or pipx, or uv, or any of various others. (not Conda though!) They differ slightly in where they install the package and how they set it up for you to use, but under the hood they're all doing the same thing.
When you see a README file that recommends a particular pip-compatible installer, you should know that you can use *any* pip-compatible installer instead. In fact, you're supposed to pick the one that best meets your needs. Unless you're a Python developer, that's probably pipx. So whenever you see `pip install <package>` or `pip install --user <package>` or so on in a README file, just mentally replace it with `pipx install <package>` and you'll probably avoid a lot of confusion.
-
pytest strongly recommend this https://docs.pytest.org/en/latest/goodpractices.html and point to https://blog.ionelmc.ro/2014/05/25/python-packaging/#the-structure for more benefits.
See also:
https://packaging.python.org/en/latest/discussions/src-layout-vs-flat-layout/
https://www.pyopensci.org/python-package-guide/package-structure-code/python-package-structure.html
https://www.b-list.org/weblog/2023/dec/15/python-packaging-src-layout/
-
@cazabon @jmsdnns Ooooh, interesting take. No disrespect but I would disagree with that pretty strongly; I have seen SO MANY PROBLEMS come from projects being importable from the project directory. Typically it's either because random Python files in the project directory also get imported and interfere with parts of the project, or because the developer makes the project importable from its directory and then concludes their job is done, without realizing that it cannot be packaged into an sdist or wheel and installed from there. Using the src layout solves both those problems - so it does have real benefits.
-
@jmsdnns Yeah that's fair, I think it didn't *really* start to catch on until recently (the last 3-ish years), and it's still not widespread enough to be a big surprise that you haven't seen it. FWIW I'm pretty plugged in to recent developments in packaging and even I only see it about half the time.
-
@covracer Off the top of my head, it could have been because they tagged 2.9.1 in the repository and then found that something was wrong with it (likely a metadata error). Rather than deleting the tag and recreating it on a later commit with the fix, which would be very poor practice, they just chose to create a new version and release that.
This is all speculation but if it is the case, it should be straightforward to confirm by looking at the project's GitHub page (or whatever they use).
-
It's release day again for setuptools-pyproject-migration! This project from @stuartl and myself helps you convert your setuptools configurations to modern standard-compliant pyproject.toml files. v0.3 brings many bug fixes; I think we are rapidly approaching the point where the thing actually works 😛
We'd be very grateful if you try it and let us know how it works for you!
https://setuptools-pyproject-migration.readthedocs.io/en/stable/
https://github.com/diazona/setuptools-pyproject-migration -
#PythonPackaging woes: I just realized one killer feature of setuptools (with setuptools_scm) which no other build backend I've used seems to have: the ability to exclude files not tracked in Git from an sdist. Which is super useful since I always have a bunch of random junk hanging out in my project development directory. Apparently I've been using hatch (with hatch-vcs) for a couple years without ever realizing it doesn't do that.
Anyone know of other backends that can do this?
-
#PythonPackaging woes... 99% of the time tox is a great tool, but any time I want to do something complex with it (like in this case, using the package_env option) its behavior rapidly becomes extremely confusing and often inconsistent with the documentation, as far as I can tell.
If anyone knows a good guide to using package_env or has had success with it, I'd be interested to hear about it!
-
📣 new Python package alert!
Eliot Robson was kind enough to write up a blog post about their latest package, automata, which allows for the simulation of reading input and higher-level manipulation of the corresponding languages using specialized algorithms for:
1️⃣ Finite-state automata
2️⃣ Pushdown automata
3️⃣ Turing machines
Our latest newsletter gets into the details - be sure to check it out: https://www.linkedin.com/pulse/automata-simulation-manipulation-pyopensci-jjdvc/
#Python #pyOpenSci #OpenSource #OpenScience #PythonPackaging #automata
-
This will be of extremely niche interest 😛 but why not: I'm working on how setuptools-pyproject-migration (https://github.com/diazona/setuptools-pyproject-migration) handles the `long_description`/`readme` field. In `pyproject.toml`, we can give this field in three ways:
- Filename with a content type
- Filename without a content type, but it's expected that the type will be inferred from the file's extension
- Raw string with a content typeBut setuptools also allows giving the long description as a raw string with no associated content type. Q: How should that be converted to `pyproject.toml`?
- Write the string to a file with no extension, knowing that some tools will choke because they can't infer a content type
- Keep it as a string and guess a content type as per the core metadata spec (https://packaging.python.org/en/latest/specifications/core-metadata/#description-content-type), but this is difficult to implement
- Make the user specify the content type manually
- Something else?Adding a poll b/c why not, but I'm more interested in the discussion
-
Python packaging can be a thorny subject, but there's no reason you have to go it alone! This week's pyOpenSci newsletter is a fantastic read from our Executive Director and Founder, @leahawasser, where she'll walk you through her latest PyCon talk: Friends don't let friends package alone!
https://www.linkedin.com/pulse/friends-dont-let-package-alone-my-python-packaging-talk-pycon-jbm3c/
-
@fohrloop @brettcannon @venthur @fcodvpt Oh interesting. That could be, but I do seem to remember that flit will omit any Python files other than a single top-level directory or Python file whose name matches the package name. Or something like that. Maybe that causes it to exclude tests and docs.
Every build backend has its own rules about what files it includes in an sdist, and it wouldn't surprise me if flit is one of the most conservative in that sense. Of course, that probably does mean that if you ever want to get your package included in a Linux distro or some other context where tests and/or documentation are important, you need to use something other than flit.
-
@fohrloop @brettcannon @venthur @fcodvpt FWIW it's not actually guaranteed that sdists have tests and docs included. I mean, ultimately an sdist is just a .tar.gz archive that follows a few standards, but I don't think those standards govern what goes in the repo, except for the PKG-INFO file which needs to contain some metadata. (Technically I don't think an sdist even needs to contain the package's own source code! You could make a valid sdist with almost nothing in it - useless, but valid.)
However, the way most build tools are configured, they'll put everything in the sdist by default, so it's common to have tests+docs in there, and a certain subset of consumers have come to rely on that.
-
@fohrloop @brettcannon @venthur @fcodvpt One thing I've heard is that packagers for downstream repositories (e.g. Linux distribution package managers) prefer or even insist on sdists because they need the test code and/or documentation. There can be other tools that are trying to do things other than installing your package that can't work with a wheel, they need an sdist.
BTW you can use `python -m build` to build a project and get both the sdist and wheel "for free".
And yeah, dynamic versioning is great. I've had so many problems with hard-coding the version number in a file; IMO it's so much easier to just determine it from the tag. So this is the "killer feature" that makes me choose hatch (or setuptools back in the day before hatch supported it) over other backends.
-
New blog post on user support frustration, its causes, and how we could build the "infrastructure of equanimity" in #opensource, including ideas for potential cross-project tools & practices.
Shout-outs to @davidism, Heidi Waterhouse, @offby1, @jacob, Nicole Harris, @bernard, + @georgia for work & conversations that I built on in this piece.
#maintainer #maintainership #FLOSS #UX #UserExperience #sustainability #ProjectManagement #Python #PythonPackaging #burnout