5 ms·

https://www.pypa.io/ https://www.pypa.io/ ? "The PyPA publishes the Python Packaging User Guide [1], which is the authoritative resource on how to package, pub

https://www.pypa.io/ https://www.pypa.io/ ? "The PyPA publishes the Python Packaging User Guide [1], which is the authoritative resource on how to package, publish, and install Python projects using current tools." [1]: https://packaging.python.org/ https://packaging.python.org/

avidphantasm 4y ago
Last I checked, and I could be missing something, PyPA doesn’t say how to package extensions using the new pyproject.toml style. I happen to be using SWIG (which I inherited), which suggests the use of setup.py alone. I just haven’t had time to figure out the right path.
- blooalien 4y ago
  I dunno about using it with SWIG but I've had a pretty good experience using Poetry [1] for pure Python stuff myself. That uses pyproject.toml to declare all your project's dependencies, but no idea if it can be used with SWIG or not. I'd have to research it… [1]: https://python-poetry.org/ https://python-poetry.org/ Edit: Some quick cursory research seems to indicate I'd have to do some custom scripting to integrate SWIG into the process.
  - filmor 4y ago
    Poetry is currently not useful for extensions: https://github.com/python-poetry/poetry/issues/2740 https://github.com/python-poetry/poetry/issues/2740
- filmor 4y ago
  You can migrate a lot out of your setup.py into the pyproject.toml nowadays (https://setuptools.pypa.io/en/latest/userguide/pyproject_config.html https://setuptools.pypa.io/en/latest/userguide/pyproject_con...).
- xapata 4y ago
  Wouldn't you make a wheel?
  - blooalien 4y ago
    Indeed… That does seem to be the best way to go about this particular task.
- ihusasmiiu 4y ago
  I don't genuinely understand what's wrong with setup.py and why people wouldn't just use setuptools, as it is even suggested by PyPA. IMHO Python should improve what it already has instead of pushing the usage of third party tools for a core component such as packaging. For all my Python projects I just use setuptools and the built-in venv module for isolation. What I feel it's really missing is an official way to have multiple Python version installed.
  - nine_k 4y ago
    Isn't installing different versions an OS concern, not the Python's concern? I bet Debian and NixOS have very different takes on that, to say nothing of macOS and Windows. I also suppose that pyenv and poetry exist and solve that to a reasonable extent.
    - ihusasmiiu 4y ago
      One could say that providing Python modules is an OS concern as well. Debian IMHO has the worst take on that (see the venv module). Pyenv definitely solves it, but I talked about an officially supported solution.
  - angrais 4y ago
    pyenv will solve your multiple python on one machine problem :)
  - Doxin 4y ago
    > What I feel it's really missing is an official way to have multiple Python version installed. Install them into different directories. There's nothing about python that makes this at all hard or even tricky.
avian 4y ago
My comment on that guide is that it expects everyone to run the latest version of Python. Last time I made a package following it, it turned out to be unusable in practice. I had to go back to setup.py and hunt down old guides and copy-paste parts from known-good packages to get something that was working for everyone involved. I'm not even talking about Python 2 (which can still be found in the wild). Something like Python 3.5 is still very common out there

avidphantasm 4y ago

Last I checked, and I could be missing something, PyPA doesn’t say how to package extensions using the new pyproject.toml style. I happen to be using SWIG (which I inherited), which suggests the use of setup.py alone. I just haven’t had time to figure out the right path.

blooalien 4y ago
I dunno about using it with SWIG but I've had a pretty good experience using Poetry [1] for pure Python stuff myself. That uses pyproject.toml to declare all your project's dependencies, but no idea if it can be used with SWIG or not. I'd have to research it… [1]: https://python-poetry.org/ https://python-poetry.org/ Edit: Some quick cursory research seems to indicate I'd have to do some custom scripting to integrate SWIG into the process.
- filmor 4y ago
  Poetry is currently not useful for extensions: https://github.com/python-poetry/poetry/issues/2740 https://github.com/python-poetry/poetry/issues/2740
filmor 4y ago
You can migrate a lot out of your setup.py into the pyproject.toml nowadays (https://setuptools.pypa.io/en/latest/userguide/pyproject_config.html https://setuptools.pypa.io/en/latest/userguide/pyproject_con...).
xapata 4y ago
Wouldn't you make a wheel?
- blooalien 4y ago
  Indeed… That does seem to be the best way to go about this particular task.
ihusasmiiu 4y ago
I don't genuinely understand what's wrong with setup.py and why people wouldn't just use setuptools, as it is even suggested by PyPA. IMHO Python should improve what it already has instead of pushing the usage of third party tools for a core component such as packaging. For all my Python projects I just use setuptools and the built-in venv module for isolation. What I feel it's really missing is an official way to have multiple Python version installed.
- nine_k 4y ago
  Isn't installing different versions an OS concern, not the Python's concern? I bet Debian and NixOS have very different takes on that, to say nothing of macOS and Windows. I also suppose that pyenv and poetry exist and solve that to a reasonable extent.
  - ihusasmiiu 4y ago
    One could say that providing Python modules is an OS concern as well. Debian IMHO has the worst take on that (see the venv module). Pyenv definitely solves it, but I talked about an officially supported solution.
- angrais 4y ago
  pyenv will solve your multiple python on one machine problem :)
- Doxin 4y ago
  > What I feel it's really missing is an official way to have multiple Python version installed. Install them into different directories. There's nothing about python that makes this at all hard or even tricky.

avian 4y ago

My comment on that guide is that it expects everyone to run the latest version of Python. Last time I made a package following it, it turned out to be unusable in practice. I had to go back to setup.py and hunt down old guides and copy-paste parts from known-good packages to get something that was working for everyone involved. I'm not even talking about Python 2 (which can still be found in the wild). Something like Python 3.5 is still very common out there