home.social

#pythonpackaging — Public Fediverse posts

Live and recent posts from across the Fediverse tagged #pythonpackaging, aggregated by home.social.

  1. @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.

    #Python #PythonPackaging

  2. How uv got so fast: nesbitt.io/2025/12/26/how-uv-g

    "uv is fast because of what it doesn’t do, not because of what language it’s written in."

    #python #PythonPackaging #uv #pip #rust

  3. 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.
    github.com/openvenues/pypostal

    #Python #PythonPackaging

  4. 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…

    #Python #PythonPackaging

  5. 🐍 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

  6. Join our hands-on 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 support

    No installs needed—GitHub Codespaces works too!

    📅 July 8, 8am–12pm PT
    📍 Room 316, Greater Tacoma Convention Center

    Workshop info: pyopensci.org/events/pyopensci

    More SciPy events: pyopensci.org/blog/pyopensci-a

  7. 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 support

    No installs needed—GitHub Codespaces works too!

    📅 July 8, 8am–12pm PT
    📍 Room 316, Greater Tacoma Convention Center

    Workshop info: pyopensci.org/events/pyopensci

    More SciPy events: pyopensci.org/blog/pyopensci-a

    #Python #OpenSource #PyOpenSci #PythonPackaging

  8. 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 support

    No installs needed—GitHub Codespaces works too!

    📅 July 8, 8am–12pm PT
    📍 Room 316, Greater Tacoma Convention Center

    Workshop info: pyopensci.org/events/pyopensci

    More SciPy events: pyopensci.org/blog/pyopensci-a

    #Python #OpenSource #PyOpenSci #PythonPackaging

  9. 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 support

    No installs needed—GitHub Codespaces works too!

    📅 July 8, 8am–12pm PT
    📍 Room 316, Greater Tacoma Convention Center

    Workshop info: pyopensci.org/events/pyopensci

    More SciPy events: pyopensci.org/blog/pyopensci-a

    #Python #OpenSource #PyOpenSci #PythonPackaging

  10. 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 support

    No installs needed—GitHub Codespaces works too!

    📅 July 8, 8am–12pm PT
    📍 Room 316, Greater Tacoma Convention Center

    Workshop info: pyopensci.org/events/pyopensci

    More SciPy events: pyopensci.org/blog/pyopensci-a

    #Python #OpenSource #PyOpenSci #PythonPackaging

  11. 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! youtu.be/XAq-HnPU4XM

  12. 🚨 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 flaws

    Read more in our latest blog post:
    🔗 pyopensci.org/blog/python-pack

  13. 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

  14. 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

  15. 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

  16. 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

  17. 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

  18. 🥳 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 topics

    bit.ly/pyosFF2024

    We can't wait to see you there!

    #Python #OpenSource #OpenScience #pyOSFallFestival #Quarto #GreatTables #PythonPackaging

  19. 🥳 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 topics

    bit.ly/pyosFF2024

    We can't wait to see you there!

  20. 🥳 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 topics

    bit.ly/pyosFF2024

    We can't wait to see you there!

    #Python #OpenSource #OpenScience #pyOSFallFestival #Quarto #GreatTables #PythonPackaging

  21. 🥳 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 topics

    bit.ly/pyosFF2024

    We can't wait to see you there!

    #Python #OpenSource #OpenScience #pyOSFallFestival #Quarto #GreatTables #PythonPackaging

  22. 🥳 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 topics

    bit.ly/pyosFF2024

    We can't wait to see you there!

    #Python #OpenSource #OpenScience #pyOSFallFestival #Quarto #GreatTables #PythonPackaging

  23. 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

    stackoverflow.com/q/78974383/3

    #Python3 #python_programming #PythonPackaging #programmingadvice

  24. 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

    stackoverflow.com/q/78974383/3

    #Python3 #python_programming #PythonPackaging #programmingadvice

  25. 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

    stackoverflow.com/q/78974383/3

    #Python3 #python_programming #PythonPackaging #programmingadvice

  26. 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

    stackoverflow.com/q/78974383/3

    #Python3 #python_programming #PythonPackaging #programmingadvice

  27. 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

    stackoverflow.com/q/78974383/3

    #Python3 #python_programming #PythonPackaging #programmingadvice

  28. @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.

    #Python #PythonPackaging

  29. @hugovk @jmsdnns Indeed, I think pytest was one of my main motivations for adopting the src layout when I first did so

    #Python #PythonPackaging

  30. @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.

    #Python #PythonPackaging

  31. @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.

    #Python #PythonPackaging

  32. @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).

    #Python #PythonPackaging #programming

  33. 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!

    setuptools-pyproject-migration
    github.com/diazona/setuptools-

    #Python #PythonPackaging #setuptools

  34. #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?

    #Python

  35. #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!

    #Python

  36. 📣 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: linkedin.com/pulse/automata-si

  37. This will be of extremely niche interest 😛 but why not: I'm working on how setuptools-pyproject-migration (github.com/diazona/setuptools-) 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 type

    But 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 (packaging.python.org/en/latest), 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 #PythonPackaging

  38. 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!

    linkedin.com/pulse/friends-don

  39. @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.

    #Python #PythonPackaging

  40. @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.

    #Python #PythonPackaging

  41. @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.

    #Python #PythonPackaging

  42. 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.

    harihareswara.net/posts/2023/u

    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