171–180 of 325 posts
Absurd discussions about micro features in packaging tools while ignoring that huge security elephant - disgusting.
Yo brotha, go on pip loading my exploits from your amateurish distribution infra! RIDICULOUS!
Earlier quoted context omitted.
> Are there any other programming languages whose package-management comes close to this level of intricacy and complexity? I think many do. Ruby, Node, Erlang/Elixir, Java, Go, Rust, dotnet, C... I’m having trouble thinking of a modern language that doesn’t have such package management mechanisms. For many people doing anything more than writing one-off scripts, and especially for anyone who collaborates with others…
But all your examples are simple and reliable tools with a minimum of intricacy. My criticism isn’t about having a package-management story. It’s about having a terrible and complex one.
If you think any of the listed examples have “simple” package management tools, I question how deeply you have used any of them. NPM has ~60 commands and hundreds of subcommands each with multiple option flags, and probably hundreds more config options. Gem/Bundle is similar, etc.
If anything, Python is trying to catch up in how complex it’s package managers can be.
Pipenv has spawned so much controvery.. One big shitfest. Python packaging in general is such a messy ecosystem
Do you think Poetry solves this package management mess?
Earlier quoted context omitted.
But then you're suddenly responsible for keeping track of your subdependencies and updating the versions of each that you want. That should be up to the dependencies. Also if you manage to drop a dependency, you don't have an easy way to remove the things from requirements.txt that are only there because they're a subdependency. Putting it all in one requirements.txt is just too simplistic.
If I had such need, I guess I could have two versions of the requirements.txt: - One with direct dependencies (versions pinned) - One with direct dependencies + subdependencies (pip freeze output) Am I being too naive ? (obviously yes if such tool as pipenv exists, but I'm trying to figure why people need *.lock files).
This is all MIT licensed, if people care so much, why has nobody forked this? Why are people talking about jumping ship to a completely different project instead of forking and cutting a new release from there?
It looks like 1.4k people have forked it. The question is, which fork do I use? The problem is not that the source is unable to be updated, the problem is how to you organize peoples' efforts under a trusted maintainer long term? How do I know which forking effort to trust? My understanding is that that's kind of the point of groups like the "Python Packaging Authority". So if they're not going to merge pull requests…
Return the forks of developers who have publicly stated they'd like to take over maintenance of this project.
I'd bet that narrows it to less than ten.
Now-- have a look at the blog posts where these maintainers explain their plan to sustain the project going forward and choose the most persuasive one.
I'd bet it's less than one.
Short circuited, problem solved. :)
Earlier quoted context omitted.
There is no difference for the average user. I'm not going to use the code in master, I will use a package from pip, pipenv or otherwise.
And even if you did, there's no guarantee that the work in master is actually in a sane state. Some try to follow models like master is always runnable, or tested/built by ci/cd, but it's often simply not the case. I've worked on atleast a few open source projects where I'd pull and build master, trying to obtain a particular bugfix, and it would fail, and I'd have to randomly rollback commits until I found a working…
Earlier quoted context omitted.
But then you're suddenly responsible for keeping track of your subdependencies and updating the versions of each that you want. That should be up to the dependencies. Also if you manage to drop a dependency, you don't have an easy way to remove the things from requirements.txt that are only there because they're a subdependency. Putting it all in one requirements.txt is just too simplistic.
If I had such need, I guess I could have two versions of the requirements.txt: - One with direct dependencies (versions pinned) - One with direct dependencies + subdependencies (pip freeze output) Am I being too naive ? (obviously yes if such tool as pipenv exists, but I'm trying to figure why people need *.lock files).
It also adds dependency management. If one subdependency is library_a > 1.0, and another is library_b So in my mind, that's what pipenv is -- pip, virtualenv, those two files, plus dependency management.
Earlier quoted context omitted.
I thought NPM was everyone's favourite hated package manager/repository?
The faults aren't so much with the actual NPM software as with the whole ecosystem. The real root of the problem IMO is that Javascript has such a tiny std lib compared to other popular languages that have package management systems. This encourages lots of people who are missing various functions normally found in std libs to write packages implementing various combinations of those functions. Those who are writing…
Earlier quoted context omitted.
But then you're suddenly responsible for keeping track of your subdependencies and updating the versions of each that you want. That should be up to the dependencies. Also if you manage to drop a dependency, you don't have an easy way to remove the things from requirements.txt that are only there because they're a subdependency. Putting it all in one requirements.txt is just too simplistic.
If I had such need, I guess I could have two versions of the requirements.txt: - One with direct dependencies (versions pinned) - One with direct dependencies + subdependencies (pip freeze output) Am I being too naive ? (obviously yes if such tool as pipenv exists, but I'm trying to figure why people need *.lock files).
That's a lock file...
I’ve heard good things about pip-tools: https://github.com/jazzband/pip-tools