Cargo is strictly worse than any of the solutions for python. Doing even the simplest things seems to involve pulling down and compiling hundreds of dependencies.
This is... Not a bad thing? Compiling your dependencies into your standalone executable is like butter, no dependency hell, no virtual environments or containers to avoid said hell. You release a program that has everything it needs to run, it's as good as it gets IMO.
The problem that the resulting program ends up too large for my users to download, because it depended on libtwoplustwo that in turn depended on libkitchensink.
I see a lot of package managers I never head of, am a happy venv & pip user. One of the key faults of pip is what happens when you decide to remove a dependency. Removing a dependency does not actually remove the sub-dependencies that were brought in by the original dependency, leaving a lot of potential cruft. This is not really an issue if your virtual environments are disposable. Just nuke and recreate venv from s…
I do a lot of maintenance work and every time I've encountered a (complex) project set up in this way that's older than ~6 months, it's bitrotted from breaking changes in the dependencies. The python ecosystem does not stand still and seems quite happy to introduce breaking changes in non-major versions. To my mind, there are 3 ways to make sure your python project of today will work in 2 years time: 1. Have no depen…
What sucks is when you imply that your project will be unmaintained for 2 years, without any kind of update (not even basic security upgrades). This is a not a project, this is abandonware from day 1.
This is... Not a bad thing? Compiling your dependencies into your standalone executable is like butter, no dependency hell, no virtual environments or containers to avoid said hell. You release a program that has everything it needs to run, it's as good as it gets IMO.
The problem that the resulting program ends up too large for my users to download, because it depended on libtwoplustwo that in turn depended on libkitchensink.
The rust compiler does not include in your binary any unused code. Unless libtwoplustwo uses the entirety of libkitchensink, the latter is not entirely included in your binary.
This is not true for python, or external libraries, or appimages, or docker containers.
The people who say "just use pip and venv" don't understand the issue. Distutils has been ripped out of Python core, setuptools is somewhat deprecated but not really. Just don't call setup.py directly. Or use flit. Or perhaps pyproject.toml? If the latter, flit, poetry and the 100 other frontends all have a different syntax. Would you like to copy external data into the staging area while using flit? You are out of l…
And reading your post, I still do not understand your issue. Is this because you can do various stuff in various way ? Would you like a single path, which must be followed ?
I see a lot of package managers I never head of, am a happy venv & pip user. One of the key faults of pip is what happens when you decide to remove a dependency. Removing a dependency does not actually remove the sub-dependencies that were brought in by the original dependency, leaving a lot of potential cruft. This is not really an issue if your virtual environments are disposable. Just nuke and recreate venv from s…
I use the same workflow, and works for me very well. It would be cool, though, to have a wrapper around pip that adds any packages I install to the requirements file. That way I don't have to do it manually.
The problem that the resulting program ends up too large for my users to download, because it depended on libtwoplustwo that in turn depended on libkitchensink.
The rust compiler does not include in your binary any unused code. Unless libtwoplustwo uses the entirety of libkitchensink, the latter is not entirely included in your binary. This is not true for python, or external libraries, or appimages, or docker containers.
It seems to me one would have to solve the Halting Problem for that to be universally true.
Notable omission in pip-tools which many are suggesting here as being simpler: it can't write requirements files for multiple environments/platforms without running it once for each of those environments and having one file for all of them.
We settled on Poetry at the time but it has been quite unstable overall. Not so bad recently but there were a lot of issues/regressions with it over time.
For this reason I am happy to see new takes on package management, hopefully some of these will have clearer wins over the others, where you have to spend ages trying to figure out which one will do what you need.
I do a lot of maintenance work and every time I've encountered a (complex) project set up in this way that's older than ~6 months, it's bitrotted from breaking changes in the dependencies. The python ecosystem does not stand still and seems quite happy to introduce breaking changes in non-major versions. To my mind, there are 3 ways to make sure your python project of today will work in 2 years time: 1. Have no depen…
What sucks is when you imply that your project will be unmaintained for 2 years, without any kind of update (not even basic security upgrades). This is a not a project, this is abandonware from day 1.
There was a time when you wrote a software for a version of the OS and it was done (except security fixes).
I do a lot of maintenance work and every time I've encountered a (complex) project set up in this way that's older than ~6 months, it's bitrotted from breaking changes in the dependencies. The python ecosystem does not stand still and seems quite happy to introduce breaking changes in non-major versions. To my mind, there are 3 ways to make sure your python project of today will work in 2 years time: 1. Have no depen…
What sucks is when you imply that your project will be unmaintained for 2 years, without any kind of update (not even basic security upgrades). This is a not a project, this is abandonware from day 1.
Obviously my profession gives me a ton of bias but in general it seems that for most people the squeaky wheel gets the grease and once a project is working it is ignored until it stops working again because there are only so many hours in the day and management has an infinite list of demands...
And then it breaks 2 years later and I'm called in because the person who wrote it left and no one else knows how it works because they didn't write any documentation etc etc etc
The rust compiler does not include in your binary any unused code. Unless libtwoplustwo uses the entirety of libkitchensink, the latter is not entirely included in your binary. This is not true for python, or external libraries, or appimages, or docker containers.
It seems to me one would have to solve the Halting Problem for that to be universally true.
Not quite, it is pretty trivial to check what external dependencies your program calls, and what those dependencies call and so forth. I'm sure you could write a program that has a dependency chain that requires the entire database of packages in cargo (and that would he an interesting experiment). A lot of modern programming languages evaluate what code is referenced in a working program and only include used code, and the compiler enforces writing your program in such a way that it doesn't have to go over infinite possibilities to check. Of course, you have to have the entire dependency to compile for each import (and so would your user if you only distribute source code) to reference the first problem you mentioned above, and I'm sure there are ways to trick the compiler into endlessly checking dependencies or evaluating references, probably using unsafe, but that's why the compiler won't let you compile with unassigned values and has ownership and scope, you have to write your program in such a way that the compiler can tell what code will be executed at runtime or it won't compile.