4 ms·

Tell them about requirements.txt, pip freeze & virtualenv. You can also curl | bash but that doesn't mean bash is to blame, because it doesn't encourage this ba

• danenania 5y ago
  "Tell them about requirements.txt, pip freeze & virtualenv" NPM offers the same functionality with lock files.
  • oauea 5y ago
    npm install would like to have a word with your lockfile.
    • danenania 5y ago
      We're getting into minutiae here. Yes npm install will update the lock file if package.json conflicts. But it certainly does not update every time npm install is run if you use a lock file, which is what your earlier comment (and those of others) mistakenly imply. If you have ~1.0.0 in package.json and 1.0.11 specified in the lock file, but then bump package.json to ~1.0.12, yes npm will upgrade the package and then bump the dep in your lock file to 1.0.12. That seems fine?
      • halostatue 5y ago
        This is not my experience with how most people specify their dependencies (and the tools use by default) If you have `^1.0.0` in package.json, the version mark is `^1.0.11` in the lock file, which means that a random `npm i` or `yarn install` will install `^1.0.12` in your lock file. I more or less said this yesterday[1], but the behaviour of `yarn install --frozen-lockfile` and `npm ci` should be the _default_ behaviour. The current behaviour is demonstrably dangerous. A lockfile should remain locked without explicit action by developers. [1]: https://news.ycombinator.com/item?id=29869859 https://news.ycombinator.com/item?id=29869859
        • danenania 5y ago
          "If you have `^1.0.0` in package.json, the version mark is `^1.0.11` in the lock file, which means that a random `npm i` or `yarn install` will install `^1.0.12` in your lock file." That's not true. package-lock.json file dependencies are specified as exact versions, not ranges. If you have 1.0.11 in your lock file, npm install will always install 1.0.11 unless it no longer satisfies the version in package.json.
          • oauea 5y ago
            You're mixing up npm ci and npm install. npm install will update your lockfile. See the docs: https://docs.npmjs.com/cli/v6/configuring-npm/package-locks https://docs.npmjs.com/cli/v6/configuring-npm/package-locks
            • danenania 5y ago
              Where are you seeing that? From your link: “The presence of a package lock changes the installation behavior such that: The module tree described by the package lock is reproduced. This means reproducing the structure described in the file, using the specific files referenced in "resolved" if available, falling back to normal package resolution using "version" if one isn't. The tree is walked and any missing dependencies are installed in the usual fashion.”
          • halostatue 5y ago
            The scenario is a _little_ more complicated than I laid out, but I have seen this in practice. I _believe_ that it will happen when you have two copies of a repo and one of the copies does not have one of the dependencies. If user A (repo copy 1) adds a package with `^1.0.0` but the lockfile indicates `^1.0.11`, then user B (repo copy 2) will get `^1.0.12`. The _only_ correct behaviour for a lockfile is `=1.0.11` (I think that npm calls that `1.0.11`, but NPM’s semver specification is unnecessarily complex compared to Elixir or Ruby) unless there is an explicit update. Otherwise, you will _not_ get the same version installed for all developers.
            • 5y ago
      • oauea 5y ago
        No, that is madness. A new developer clones the repo and gets wildly different dependency versions than the previous devs tested with. Then once you PR your changes, you include that lockfile and production explodes. Insane. And yes, this is a real problem. See the thread we're posting in and how many projects it affected.
        • danenania 5y ago
          “A new developer clones the repo and gets wildly different dependency versions than the previous devs tested with.” Could you describe a scenario where you think this happens? It doesn’t if you have a lock file in version control. Do you mean if it’s not in version control?
          • deleted 5y ago
            [deleted]
• jessaustin 5y ago
  Aren't those files associated with a previous generation of python package management? At least npm hasn't been replaced half a dozen times.