319
Package managers be like (linux.community)
submitted 2 years ago by to c/programmerhumor@lemmy.ml
156 comments fedilink hide all child comments
 

Sorry Python but it is what it is.

you are viewing a single comment's thread
view the rest of the comments
[–] 73 points 2 years ago (2 children)

So you are saying that npm is better than pip?? I'm not saying pip is good, but npm?

  • permalink
  • fedilink
  • source
  • hideshow 4 child comments
    •
  • [–] 35 points 2 years ago (2 children)

    npm has a lockfile which makes it infinitely better.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 21 points 2 years ago (2 children)

    pip also has lock files

    pip freeze > requirements.txt

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 7 points 2 years ago (1 child)

    Would that just create a list of the current packages/versions without actually locking anything?

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 8 points 2 years ago* (1 child)

    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

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 3 points 2 years ago* (2 children)

    As I understand, when you update npm packages, if a package/version is specified in package-lock.json, it will not get updated past that version. But running those pip commands you mentioned is only going to affect what version gets installed initially. From what I can tell, nothing about those commands is stopping pip from eventually updating a package past what you had specified in the requirements.txt that you installed from.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 3 points 2 years ago (1 child)

    The behaviour you mention is from npm install, which will put the same exact version from the package-lock.json, if present. If not it will act as an npm update.

    npm update will always update, and rewrite the package-lock.json file with the latest version available that complies with the restrictions defined on the package.json.

    I may be wrong but, I think the difference may be that python only has the behaviour that package-lock.json offer, but not the package.json, which allows the developer to put constraints on which is the max/min version allowed to install.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 2 points 2 years ago

    If you want min-max behaviours you need to use wrappers like pipenv or jump into conda/mamba. Pip offers basic functionality because there are more advanced tools that the community uses for the more advanced use cases.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 2 points 2 years ago

    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.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 0 points 2 years ago (1 child)

    That's not a lockfile. This would be the equivalent of package.json

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] -2 points 2 years ago (2 children)

    How is it not a lock file?

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

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 0 points 2 years ago (1 child)

    Lockfile contains exact state of the npm-managed code, making it reproducible exactly the same every time.

    For example without lockfile in your package.json you can have version 5.2.x. In your working directory, you use 5.2.1, however on repo, 5.2.2 has appeared, matching your criteria. Now let's say a new bug appeared in 5.2.2.

    Now you have mismatched vendor code, that can make your code behave differently on your machine, and your coworker's machine, making you hunt for bug that wasn't even on your side.

    Lockfile prevents that by saving an actual state of vendor code.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] -2 points 2 years ago (1 child)

    Pip has Pipfile.lock.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •