3 ms·

Every "language package manager" with a lock file format and requirements file, is an inferior, ad hoc, formally-specified, error-prone, incompatible reimplemen

by cxr 2y ago

Every "language package manager" with a lock file format and requirements file, is an inferior, ad hoc, formally-specified, error-prone, incompatible reimplementation of half of Git. Almost every use case for a package manager is better served by Git, whether you choose to use submodules or not. If you want to do version control, use the version control system, and stop trying to do an end-run around the way it works. Previously: > I'm happy to criticize NPM the tool. The whole thing is designed as a second, crummier version control system that lives in disharmony with and on top of your base-level version control system (so it can subvert it). It's a terrible design. <https://news.ycombinator.com/item?id=37604551 https://news.ycombinator.com/item?id=37604551>

eru 2y ago
Git knows nothing about eg semantic versioning, or how to resolve different requirements from different libraries that you want to use together.
- cxr 2y ago
  Right.
  - eru 2y ago
    So it might be a decent replacement for a lock file, only.
    - cxr 2y ago
      What?
      - eru 2y ago
        Git only replaces the lock file aspect of package managers, not the version requirement resolution part. (Or the part that tells deals with eg Rust's feature selection, or different build instructions for different operation systems or versions of the language etc.)
        cxr 2y ago
        > Git only replaces the lock file aspect of package managers Nope, Git is pretty good about downloading stuff over the network, too. In fact, it's so good at it that many people using a language package manager insist you use Git at some point even when (before) using the package managers. Indeed, there's been a lot of trepidation and gnashing of teeth about whether the places where language package managers download packages from are as reliable/trustworthy as the server where the Git repo for the software project is hosted. > nothing about eg semantic versioning, or how to resolve different requirements from different libraries "[…] incompatible reimplementation of _half_ of Git."

by cxr 2y ago

eru 2y ago

Git knows nothing about eg semantic versioning, or how to resolve different requirements from different libraries that you want to use together.

cxr 2y ago
Right.
- eru 2y ago
  So it might be a decent replacement for a lock file, only.
  - cxr 2y ago
    What?
    - eru 2y ago
      Git only replaces the lock file aspect of package managers, not the version requirement resolution part. (Or the part that tells deals with eg Rust's feature selection, or different build instructions for different operation systems or versions of the language etc.)
      - cxr 2y ago
        > Git only replaces the lock file aspect of package managers Nope, Git is pretty good about downloading stuff over the network, too. In fact, it's so good at it that many people using a language package manager insist you use Git at some point even when (before) using the package managers. Indeed, there's been a lot of trepidation and gnashing of teeth about whether the places where language package managers download packages from are as reliable/trustworthy as the server where the Git repo for the software project is hosted. > nothing about eg semantic versioning, or how to resolve different requirements from different libraries "[…] incompatible reimplementation of _half_ of Git."