bjorney

Yes, which is EXACTLY like a pip freeze’d requirements.txt, storing the exact version of every package and downstream dependency you have installed

But running those pip commands you mentioned is only going to affect what version gets installed initially.

I don’t follow. If my package-lock.json specifies package X v1.1 nothing stops me from manually telling npm to install package X v1.2, it will just update my package.json and package-lock.json afterwards

If a requirements.txt specifies X==1.1, pip will install v1.1, not 1.2 or a newer version. If I THEN install package Y that depends on X>1.1, the pip install output will say 1.1 is not compatible and that it is being upgraded to 1.2 to satisfy package Y’s requirements. If package Y works fine on v1.1 and does not require the upgrade, it will leave package X at the version you had previously installed.

Would that just create a list of the current packages/versions

Yes, and all downstream dependencies

without actually locking anything?

What do you mean? Nothing stops someone from manually installing an npm package that differs from package-lock.json - this behaves the same. If you pip install -r requirements.txt it installs the exact versions specified by the package maintainer, just like npm install the only difference is python requires you to specify the “lock file” instead of implicitly reading one from the CWD

How is it not a lock file?

package.json doesn’t contain the exact version number of all downstream dependencies, this does

pip also has lock files

pip freeze > requirements.txt

But not enough to spend a few bucks on the ad-free version of the app

Rsync checks the files and only issues the copy if the file size/modified dates are different by default. Ignore existing will not overwrite a changed file afaik.

If the file is large it only sends the changed blocks (e.g. you have a 100gb database and only a dozen 4mb blocks have been modified it won’t send the full 100gb across the network)