Just use Poetry [1]. It's popular and works well. [1] https://python-poetry.org/
There are at least 5 comments in this thread saying "just use the tool I use"
How to make a Python package in 2021
141–150 of 215 posts
Re: How to make a Python package in 2021
#142I’m always glad to see Make being used. It’s such a powerful and simple tool that usually does the job just as well as more “bespoke” CLI’s for various frameworks and languages
I rather just write a bash script. It's the lowest common denominator. Make may not be installed by default in many places and it has some weird syntax quirks that make it annoying to use IMO. Here's an example of how I like to do my "bash scripts that sorta work like make": https://github.com/francislavoie/laravel-websockets-example/... basically each function is a "command", so I do like "./utils start" or whatever…
Please don't write a bash script.
Re: How to make a Python package in 2021
#143What happened to setup.py and wheels?
Re: How to make a Python package in 2021
#144The number of extra tools used in this article boggles my mind. Are you writing a simple library? Create a setup.py. Copy paste an existing setup.py and modify it to suit your purposes. Now you have a working, pip installable python package. Want to publish to PyPI? Use twine. It's standard and it's simple. You don't need complicated tooling for simple projects.
I actually think one should do the exact opposite to what you're suggesting. I've experienced modern package management through Cargo and anything below that level now seems like returning to stone age. In the python ecosystem, poorly defined packages is a wide problem. You never know what you get in the next version upgrade. So my suggestion: burn all the "simple" python packaging tools in a big fire and move eveyth…
I was hoping to see this blog post highlight poetry usage. Any good resource for this? I've already seen the official page.
Re: How to make a Python package in 2021
#145Somewhat related: I have an example repository which I've been using to keep track of the tools I use, aimed at people in a research lab who are relatively new to Python. I made it because the existing example/template repositories I found don't gel nicely with the way I like to set up and think about things. Here it is -- hope you find it useful:
Re: How to make a Python package in 2021
#146The number of extra tools used in this article boggles my mind. Are you writing a simple library? Create a setup.py. Copy paste an existing setup.py and modify it to suit your purposes. Now you have a working, pip installable python package. Want to publish to PyPI? Use twine. It's standard and it's simple. You don't need complicated tooling for simple projects.
Using setup.py does not mean "not using extra tools". It depends on setuptools, which is an "extra tools" just like flit (used in the article) or any other tool. In fact, with using only setuptools one will need a whole additional set of tools to manage things like: * virtual environments (granted, venv is now part of the stdlib, but it's still an "extra tool") * publishing to PyPI or another index (twine) * dependen…
Where is there a comprehensive poetry packaging tutorial?
Re: How to make a Python package in 2021
#147Re: How to make a Python package in 2021
#148Honestly, I don't even bother "packaging" Python tools anymore. Just put it in all in a git repo, and pip can install using pip install git+https://myg.it/repo.git
How does this work for dependencies?
And what if some of the dependencies are incompatible with the versions already on your system?
Re: How to make a Python package in 2021
#149Why not to make a Python package in 2021. Even as a long time Python user, the packaging ecosystem feels fragmented and error-prone at best. Honestly, it sours the experience of writing Python code knowing you might eventually need to make it work on another computer.
The only constant in the python community over the last twenty years are the criticisms about its packaging
Re: How to make a Python package in 2021
#150The number of extra tools used in this article boggles my mind. Are you writing a simple library? Create a setup.py. Copy paste an existing setup.py and modify it to suit your purposes. Now you have a working, pip installable python package. Want to publish to PyPI? Use twine. It's standard and it's simple. You don't need complicated tooling for simple projects.
For all the hate nodejs gets, it solved the software packaging problem. That is the sole reason npm ecosystem is so big. I have to say that it probably isn't a fare comparison because python is much older than nodejs. Python package management might very well have been state of the art in 1995.
My impression was that npm does little more than fetch code from the Web and stick it in a 'node_modules' directory. I've even seen npm used for things that aren't even JS, just bunch of files.
This approach ends up with multiple, potentially-incompatible versions of the same package in a project. True that's less of a problem in JS, since it's interpreted (deferring imports to runtime) and un(i)typed (no need to check if interfaces match up). Yet even that has lead to replacements/complements like yarn.