191–200 of 229 posts
This article is just a reminder that it may be impossible to fix the nightmare that is pythons packaging system. I'll save the python rant but this kind of software just further fragments and damages pythons reputation.
Earlier quoted context omitted.
This assumes semantic versioning and does not actually pin dependencies to the hash of their bytes, like a lockfile does.
`pip-compile --generate-hashes` is the best way to manage python dependencies. https://github.com/jazzband/pip-tools https://gist.github.com/hynek/5e85706cee589a204251b333595853...
Earlier quoted context omitted.
> The only non-system package manager that provides Python and its own toolchains - for Linux and macOS presently - which are used to compile every C, C++ and Fortran package, including Python itself is conda and the Anaconda Distribution. Nix[0] is also perfectly usable without NixOS, and provides all of that, but has far more non-Python libraries and applications packaged. It's also not constantly trying to sell yo…
Great I'll try it out, I always meant to but never got round to it. Does it work on macOS or Windows yet? What's the oldest Linux distro upon which it will run? Not sure we constantly try to sell our Enterprise product. You could look at it less cynically as we sell an Enterprise product to allow us to provide the Anaconda Distribution for free.
There's no "native" Windows support (yet), but I think it might work with some of the UNIX emulations (cygwin, mingw, wsl, etc.)
Not sure what the oldest working Linux version would be. However, NixOS has been around since 2003, so maybe quite old.
I hate python package/dependency/virtualenv management so much. Even JavaScript is preferable. I find npm very easy to wrap my head around. I do npm install ___ and it does a lookup in its repository and downloads it and its dependencies to node_modules. If I want to start fresh, I simply delete node_modules. Everything else "just works" when I invoke node myapp.js. Punto e basta. pipenv masquarades as the same thing…
See, I feel like python has a lot of those benefits and the package management doesn't need to be so complex. Seriously, python package management can be fairly simple. On most of our machines at work, it's just "virtualenv .env && source .env/bin/activate". Then you install your packages and... everything is in one directory, like node_modules in javascript. A clean reinstall is easy from there: remove the .env and…
Repeat what, manually doing a bazillion `pip install`? Another nice thing about npm is the packages.json file it creates. This allows us to simply add that to version control and then all the new dev has to do is clone and run `npm install` which reads packages.json and installs everything inside of it. I'm sure there's a way to do it in python but, like everything else I bet it's a non-intuitive multistep process.
JavaScript
==========
First time installation:
npm install express --save
npm install
rm -rf node_modules
node myapp.js
======
First time installation:
virtualenv .env
source .env/bin/activate
pip3 install requests
pip3 freeze > requirements.txt
virtualenv .env
source .env/bin/activate
pip install -r requirements.txt
rm -rf .env
[exit bash to clear environment]
[start bash]
virtualenv .env
source .env/bin/activate
python3 myapp.py
Earlier quoted context omitted.
The format of setup.cfg is whatever configparser accepts, which is different in different versions of Python.
First, it managed to work fine for setuptools for 2 years accross all recent python versions. That's because the differences are minor and edge cases. Try to use pyproject.toml in most CI toolchain just for fun... Second, the format of setup.cfg is defined in a documentation already, so there is a reference outside of configparser. Yes, the low level format is not explicitly defined (although it is implicitly): so le…
Oh but we do. Then we rationalize it away, because "this time...". Like we do for Big Rewrites.
It might have something to do with the fact that programming is mostly a craft you learn by doing it, so we overvalue "doing it again" because that's how we usually get better.
Earlier quoted context omitted.
See, I feel like python has a lot of those benefits and the package management doesn't need to be so complex. Seriously, python package management can be fairly simple. On most of our machines at work, it's just "virtualenv .env && source .env/bin/activate". Then you install your packages and... everything is in one directory, like node_modules in javascript. A clean reinstall is easy from there: remove the .env and…
> A clean reinstall is easy from there: remove the .env and just repeat. Repeat what, manually doing a bazillion `pip install`? Another nice thing about npm is the packages.json file it creates. This allows us to simply add that to version control and then all the new dev has to do is clone and run `npm install` which reads packages.json and installs everything inside of it. I'm sure there's a way to do it in python…
Wat? just deactivate before you rm.
Please do not talk about things you clearly don't know well enough (which is patently the case if you can't rememer freeze and deactivate).
> Out-of-the-box cognitive burden is several times greater
You got any stats on that, or is it just your opinion? Because to me, the completely counter-intuitive --save parameter is much more painful to remember.
The venv/pip workflow is not perfect, but what you've described is not the problem.
Earlier quoted context omitted.
> Introducing a lockfile is a big step forward for Python dependency management Huh? I'm not really familiar with the state of dependency management for Python/dynamic languages but... there's much more out there beyond just lockfiles. I'm a bit appalled Python is so far behind.
Much more for what? In this context, "lockfile" means a file listing all your project dependencies with exact versions pinned. (Not semaphore-files or anything like that. It's not even a python-specific term, e.g. npm uses package-lock.json for the same purpose.) The need for something to store all dependencies with exact versions pinned exists in any language and infrastructure, are there any better solutions than s…
Much more in the field of build tooling/package management. Pinning versions is fine, but dependency resolution is another legitimate choice.
Earlier quoted context omitted.
With pip for instance, it often happens that a transitive dependency gets updated inadvertently breaking your code. This follows from the assumption that all packages follow semantic versioning perfectly and keep backward compatibility where they should. This is not the case in practice and experience has shown it is unrealistic to have that assumption. A better way is to rely on exact versions of packages (up to a s…
How would you updated something inadvertently?
If the specific version of all subdependencies are pinned, then you have a mess on your hands of keeping track of what's actually required. You have to either manually maintain your requirements.txt, or you run the risk of removing a dependency and missing the removal of its subdependencies.
Further, you can't just upgrade everything, but dependencies might have conflicting version requirements for subdependencies.
Earlier quoted context omitted.
"What the hell is the difference?" One of the big selling points of pipenv is that you can pin the versions of the packages you use and their dependencies. None of the others do this, afaik.
`pip freeze > requirements.txt`
Earlier quoted context omitted.
`pip freeze > requirements.txt`
This assumes semantic versioning and does not actually pin dependencies to the hash of their bytes, like a lockfile does.
Pipfile.lock ensures that the tarball I download for a given package release is exactly the same as the one I downloaded during development. This closes what I consider to be a fairly significant security hole.