4 ms·

I don't understand your first bit, "install this package" isn't a thing in the java world. There are just dependencies, you don't "install" them. But this: >

I don't understand your first bit, "install this package" isn't a thing in the java world. There are just dependencies, you don't "install" them. But this: > And then to upgrade to the latest I had to manually go figure out what the latest was Yeah, in the java world you write code against specific known dependency versions. That's why when you try to build it again in a couple months, it still works. I sure wish the JS community would learn this old trick.

egeozcan 5y ago
NPM has had package locking since what feels like a million releases. I wish the Java community (which I'm actually also a part of) would stop rejecting everything that's not "the Java/enterprise way" and be humbled by exploring better alternatives, or alternatives with different tradeoffs for once.
- catdog 5y ago
  https://docs.gradle.org/current/userguide/dependency_locking.html https://docs.gradle.org/current/userguide/dependency_locking...
  - egeozcan 5y ago
    I wasn't arguing that gradle didn't have such a mechanism but thanks :)
- Larrikin 5y ago
  I think his point was more of a cultural difference. My IDE actually lints non pinned dependencies as a potential source of errors, whereas in the JS world it seems very common to not pin.
  - egeozcan 5y ago
    npm uses locks per default, and to disable that, you need to create a file called .npmrc at the root of the project and add package-lock=false to it. I don't think any popular project does that. It's also a common practice to use npm ci in all build scripts to never update packages even if they declared a version range in package.json, and package.lock not being able to satisfy package.json won't cause lock to get overwritten.
    - gkop 5y ago
      The fact that npm ci does what npm i should do (well, except for starting from scratch each time [0]), says it all. npm is a joke. [0] Yes, that's right. npm doesn't allow to to install incrementally respecting the lockfile. You can install incrementally with npm i and roll the dice, or install from scratch with npm ci to respect the lockfile. Basically the npm authors took the rm -rf node_modules/ workaround and productized it.
      - egeozcan 5y ago
        If you have a package.json and you run npm i it generates a package-lock.json from it. If you run npm i against that package.json and package-lock.json, the latter will never be updated, even if the package.json would be happy with newer versions. If you manually edit your package.json to have different ranges and run npm i and those ranges aren't compatible with your package-lock.json then the latter will be updated with version that are compatible with your package.json. Further runs of npm i will be as with 2 above. But of course you may think this behavior is a joke, I do not.
        gkop 5y ago
        How can I incrementally install exactly what’s in the lockfile, raising an error if it’s incompatible with package.json? This is what I expect npm i to do, but as far as I can tell, npm simply doesn’t support.
        egeozcan 5y ago
        > raising an error if it’s incompatible with package.json How? Why? What's your use-case?
        gkop 5y ago
        Two essential use cases: 1) For local development, I’m seeking a command I can use after pulling, to safely and quickly install any needed dependencies that have been added by others. Currently I use npm ci but it’s absurdly overkill (and therefore very slow). 2) For CI itself. I cache node_modules/ across builds, which significantly speeds up my builds. Currently I npm i, and check if lockfile changed, and if it did, checkout lockfile and npm ci. I shouldn’t need to npm ci ever unless my node_modules/ became corrupt for some reason. Because npm ci ALWAYS blows away node_modules/, it’s not a reasonable piece of everyday functionality, it’s just a semantically ambiguous way to rm -rf node_modules/ && npm i -—respect-lockfile (made up flag I wish existed). The obvious explanation is that the npm developers couldn’t figure out how to reliably reconcile node_modules/ with the lockfile, so just gave up and shipped npm ci. Or if the rm -rf node_modules/ isn’t strictly necessary for npm ci, then give me npm ci —-skip-drop-node-modules, that would be equivalent and fine for my purposes.
NateEag 5y ago
> Yeah, in the java world you write code against specific known dependency versions. That's why when you try to build it again in a couple months, it still works. I sure wish the JS community would learn this old trick. I've been writing JS with npm locked to specific, exact versions of dependencies since 2014, IIRC. Not everyone does this, obviously, but the tooling has been able to at least do a decent approximation of this for a long time (and I was and am very far from being a bleeding-edge adopter).
Aeolun 5y ago
> There are just dependencies, you don't "install" them Pray tell me where the dependency comes from then? When I add a ‘This package requires dependency x at version y’ to my gradle/maven file, it doesn’t magically appear on my system. Or rather, I think it does magically appear on my system, which is incredibly confusing.
- kaba0 5y ago
  It downloads it into cache for the first time and uses it at compile time at every subsequent build? How is it magical? Should it display ads instead and put random executables to my path? Or create a 1000000 file directory everywhere on which windows god damn chokes to open?
- jeroenhd 5y ago
  The dependency comes from the list of repositories you provide. Even in nodejs you don't manually enter the full URL to an NPM package. You just yarn add node-ipc==10.1 and your tooling will figure it out on its own. If you enable the general maven repository (the maven() you see at the top of many gradle build scripts), you'll get the code from maven. If you also add your personal repositories (which most people probably don't have), you'll get packages from there as well. I'm not sure how you add a second repository to node package managers, but I assume it's possible in some way without specifying the http download url. The biggest difference between the two ways of package management in my opinion is that node packages are just a word or two and Java packages are a full com.example.product.service.package name. That's a lot better in my opinion as it distinguishes between projects much more easily. I thought node-ipc was related to the nodejs project, for example. Some nodejs packages use namespaces, but most don't. Another difference is that nodejs has tons of tiny packages (I'll never get over how silly it is that is-odd and is-even appeared in my node folder by transitive dependencies) whereas the Java world generally uses huge packages almost exclusively. This leads to more boilerplate code (actually having to write simple functions like that yourself), but also to less dependencies that can break.
kaba0 5y ago
To add, gradle also has dependency check as a feature which will show possibly out of date packages.
lostcolony 5y ago
Okay - "Download and make this package available to my code", if that makes you feel better. "npm install (dependency name)" will 'download and make this package available to my code' from the NPM repository, for the current node project you're in. I can also specify custom repos to use, rather than NPM, if so desired. Gradle's default is "nah, go find the fully qualified URL package name and version number for me and paste it in the gradle build file for me, in the right location". Once you do that in Node, the package lock will specify what version you've downloaded, to make it a repeatable build. You can tweak it to indicate you want to pin the version at a given levels, as well; that's done in one place, and separately from the package-lock file that gets generated, that tells you what -actually- is being used. My follow up point is that when that version eventually goes stale, it's as simple as 'npm outdated' to determine if there's something more recent, and 'npm update' to update everything (based on whether you've pinned to a major/minor in your dependency list). You can also update specific packages with 'npm update (package name)'. I sure wish the Java community would learn this obvious 'trick' that every OS package manager enables. I know I want Jackson, say, I should be able to say "gradle install jackson" or whatever, and it would tell me all the options in the repo with jackson in the name. Then 'gradle install jackson com.fasterxml.jackson.core' and it would add that to my gradle file, with the most recent stable version. And 'gradle update jackson' would seek to update that dependency to the latest stable (with some syntax to pin the release, major, and maybe the full version, to enable 'gradle update' to update everything within a particularly defined scope).

egeozcan 5y ago

NPM has had package locking since what feels like a million releases. I wish the Java community (which I'm actually also a part of) would stop rejecting everything that's not "the Java/enterprise way" and be humbled by exploring better alternatives, or alternatives with different tradeoffs for once.

catdog 5y ago
https://docs.gradle.org/current/userguide/dependency_locking.html https://docs.gradle.org/current/userguide/dependency_locking...
- egeozcan 5y ago
  I wasn't arguing that gradle didn't have such a mechanism but thanks :)
Larrikin 5y ago
I think his point was more of a cultural difference. My IDE actually lints non pinned dependencies as a potential source of errors, whereas in the JS world it seems very common to not pin.
- egeozcan 5y ago
  npm uses locks per default, and to disable that, you need to create a file called .npmrc at the root of the project and add package-lock=false to it. I don't think any popular project does that. It's also a common practice to use npm ci in all build scripts to never update packages even if they declared a version range in package.json, and package.lock not being able to satisfy package.json won't cause lock to get overwritten.
  - gkop 5y ago
    The fact that npm ci does what npm i should do (well, except for starting from scratch each time [0]), says it all. npm is a joke. [0] Yes, that's right. npm doesn't allow to to install incrementally respecting the lockfile. You can install incrementally with npm i and roll the dice, or install from scratch with npm ci to respect the lockfile. Basically the npm authors took the rm -rf node_modules/ workaround and productized it.
    - egeozcan 5y ago
      If you have a package.json and you run npm i it generates a package-lock.json from it. If you run npm i against that package.json and package-lock.json, the latter will never be updated, even if the package.json would be happy with newer versions. If you manually edit your package.json to have different ranges and run npm i and those ranges aren't compatible with your package-lock.json then the latter will be updated with version that are compatible with your package.json. Further runs of npm i will be as with 2 above. But of course you may think this behavior is a joke, I do not.
      - gkop 5y ago
        How can I incrementally install exactly what’s in the lockfile, raising an error if it’s incompatible with package.json? This is what I expect npm i to do, but as far as I can tell, npm simply doesn’t support.
        egeozcan 5y ago
        > raising an error if it’s incompatible with package.json How? Why? What's your use-case?
        gkop 5y ago
        Two essential use cases: 1) For local development, I’m seeking a command I can use after pulling, to safely and quickly install any needed dependencies that have been added by others. Currently I use npm ci but it’s absurdly overkill (and therefore very slow). 2) For CI itself. I cache node_modules/ across builds, which significantly speeds up my builds. Currently I npm i, and check if lockfile changed, and if it did, checkout lockfile and npm ci. I shouldn’t need to npm ci ever unless my node_modules/ became corrupt for some reason. Because npm ci ALWAYS blows away node_modules/, it’s not a reasonable piece of everyday functionality, it’s just a semantically ambiguous way to rm -rf node_modules/ && npm i -—respect-lockfile (made up flag I wish existed). The obvious explanation is that the npm developers couldn’t figure out how to reliably reconcile node_modules/ with the lockfile, so just gave up and shipped npm ci. Or if the rm -rf node_modules/ isn’t strictly necessary for npm ci, then give me npm ci —-skip-drop-node-modules, that would be equivalent and fine for my purposes.

NateEag 5y ago

> Yeah, in the java world you write code against specific known dependency versions. That's why when you try to build it again in a couple months, it still works. I sure wish the JS community would learn this old trick. I've been writing JS with npm locked to specific, exact versions of dependencies since 2014, IIRC. Not everyone does this, obviously, but the tooling has been able to at least do a decent approximation of this for a long time (and I was and am very far from being a bleeding-edge adopter).

Aeolun 5y ago

> There are just dependencies, you don't "install" them Pray tell me where the dependency comes from then? When I add a ‘This package requires dependency x at version y’ to my gradle/maven file, it doesn’t magically appear on my system. Or rather, I think it does magically appear on my system, which is incredibly confusing.

kaba0 5y ago
It downloads it into cache for the first time and uses it at compile time at every subsequent build? How is it magical? Should it display ads instead and put random executables to my path? Or create a 1000000 file directory everywhere on which windows god damn chokes to open?
jeroenhd 5y ago
The dependency comes from the list of repositories you provide. Even in nodejs you don't manually enter the full URL to an NPM package. You just yarn add node-ipc==10.1 and your tooling will figure it out on its own. If you enable the general maven repository (the maven() you see at the top of many gradle build scripts), you'll get the code from maven. If you also add your personal repositories (which most people probably don't have), you'll get packages from there as well. I'm not sure how you add a second repository to node package managers, but I assume it's possible in some way without specifying the http download url. The biggest difference between the two ways of package management in my opinion is that node packages are just a word or two and Java packages are a full com.example.product.service.package name. That's a lot better in my opinion as it distinguishes between projects much more easily. I thought node-ipc was related to the nodejs project, for example. Some nodejs packages use namespaces, but most don't. Another difference is that nodejs has tons of tiny packages (I'll never get over how silly it is that is-odd and is-even appeared in my node folder by transitive dependencies) whereas the Java world generally uses huge packages almost exclusively. This leads to more boilerplate code (actually having to write simple functions like that yourself), but also to less dependencies that can break.

kaba0 5y ago

To add, gradle also has dependency check as a feature which will show possibly out of date packages.

lostcolony 5y ago

Okay - "Download and make this package available to my code", if that makes you feel better. "npm install (dependency name)" will 'download and make this package available to my code' from the NPM repository, for the current node project you're in. I can also specify custom repos to use, rather than NPM, if so desired. Gradle's default is "nah, go find the fully qualified URL package name and version number for me and paste it in the gradle build file for me, in the right location". Once you do that in Node, the package lock will specify what version you've downloaded, to make it a repeatable build. You can tweak it to indicate you want to pin the version at a given levels, as well; that's done in one place, and separately from the package-lock file that gets generated, that tells you what -actually- is being used. My follow up point is that when that version eventually goes stale, it's as simple as 'npm outdated' to determine if there's something more recent, and 'npm update' to update everything (based on whether you've pinned to a major/minor in your dependency list). You can also update specific packages with 'npm update (package name)'. I sure wish the Java community would learn this obvious 'trick' that every OS package manager enables. I know I want Jackson, say, I should be able to say "gradle install jackson" or whatever, and it would tell me all the options in the repo with jackson in the name. Then 'gradle install jackson com.fasterxml.jackson.core' and it would add that to my gradle file, with the most recent stable version. And 'gradle update jackson' would seek to update that dependency to the latest stable (with some syntax to pin the release, major, and maybe the full version, to enable 'gradle update' to update everything within a particularly defined scope).