151–160 of 215 posts
I’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’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
There are a bunch of lightweight alternatives to Make out there (I hear Ninja is pretty good). My personal preference is Nix these days (although that's quite heavyweight).
`gem` from Ruby does that (well, it doesn't 2 AFAIK but at least it does 1)
I’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
If you want to see a powerful and actually simple tool that does the job, take a look at DJB redo: https://redo.readthedocs.io/en/latest/
Earlier quoted context omitted.
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…
Bit of a side note but remember cargo learned a lot from generations of package managers, across languages. It essentially represents some of the best that package managers have to offer. You only get that kind of result by starting from scratch every few years (as in, rust started from scratch when the Node/NPM ecosystem had been around for years to steal ideas from, Haskell had been around for years to steal langua…
The 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.
This is bad advice. Do not create a setup.py for a new package. (Keeping setup.py for an old package can be okay.) The author is correct that you want a tool such as flit or poetry which will work with pyproject.toml. Setting up a basic package will be no harder than using setuptools, and it is much more future-proof. You won't have to copy-paste some other crufty setup config either. It is fair that you don't need a…
Earlier quoted context omitted.
Default way is pip freeze which I feel is too verbose, is tracking every dependency of django worth it?
Yes. Also, check pip-tools by jazzband.
Why 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.
What I actually like is using the system package manager to install stuff. pacman -s or apt-get install
letting multiple packaging systems muck with your system is a recipe for hurt somewhere down the line.
Earlier quoted context omitted.
Bit of a side note but remember cargo learned a lot from generations of package managers, across languages. It essentially represents some of the best that package managers have to offer. You only get that kind of result by starting from scratch every few years (as in, rust started from scratch when the Node/NPM ecosystem had been around for years to steal ideas from, Haskell had been around for years to steal langua…
Cargo is not hugely different from Maven which has been working fine for over a decade. Yes, it takes some polished ideas from other systems, but Python has had more packaging tools come and go than several other ecosystems put together.
A lot of ecosystems put on some solid horse blinders in order to avoid Java at all costs (Javascript/Node/NPM being another example). They've avoided good ideas from Java for more than a decade.