It does raise the question of if hosters should rely on engines at all... What if there's was a way to say in package.json this an 'app' vs a 'library'. Then I could somehow indicate in package.json what version of node my app requires, but do it in a way that is agnostic to host?
Sent from my Windows Phone From: Isaac Schlueter Sent: 6/28/2012 12:33 PM To: [email protected] Subject: Re: [nodejs] Re: remove "engines" from package.json? On Thu, Jun 28, 2012 at 6:10 AM, Matt <[email protected]> wrote: > I think it's a dumb idea, sorry - why even have the "engines" flag now? Indeed. Removing it entirely was my first suggestion :) > Are we next going to have dependenciesStrict? No, dependencies are a fundamentally different sort of thing. You can have multiple different copies of a js lib in memory, but you can't be running on multiple different versions of node at once. The engines restriction is a way for author A to prevent author B from upgrading, which is bad. > What was wrong with the fix I suggested? I see two things you suggested. (Were there more that I'm missing?) > What CPAN does is always get the most recent, and if it fails because > of a reason like this (in Perl terms, the Makefile.PL has a "use <version>" > tag), it just fails. To get an older version you have to ask for that version > specifically. Would this not work here? That's basically what I'm proposing as the default. Install the latest available, and if it breaks, oh well. The "engines" restriction is thus an advisory warning. npm != CPAN. In many ways, CPAN is better (mostly owing to many more years), but in others, npm is better (mostly owing to being invented in an era when CPAN already existed.) "Just try the latest and then fail" is not exactly the npm way, and making npm behave exactly like CPAN would be a bit silly. > if (node version > package's "engines" tag), then don't track back to look > for older versions. The problem is that it's a range, not a single value. (Though a single semver value IS a valid range, just a very small one.) What does it mean to be "greater than" a range like "0.5.4 || 0.5.6 || 0.8 || <=0.9.4"? To make that a meaningful question, we'd have to loop over all the ||-separated comparators, parse each into a "simple range" (ie, a collection of space-separated /^((?:[<>])=?)({semver})/ tokens), and then find the max of those that is a < or <= or =. If the max is <, then the version would have to be >={semver}, and if it is <= or =, then it'd have to be >{semver}. So, then you'd have a set of maximums, and find the max of those? So, for the range above, >{range} would mean >0.9.4. In other words, version ranges are not necessarily contiguous or differentiable. They have gaps. We can decide what "greater than a range" means, but it's not quite as trivial as just skipping the question entirely, and I'm not sure that the benefit is a big enough deal to matter. On Wed, Jun 27, 2012 at 11:04 PM, Vitaly Puzrin <[email protected]> wrote: > From the other hand, users never read warnings. If i've marked my module as >>= 0.6, > then i'll get complains now, that it produces strange bugs under 0.4. Vitaly, I think some of your foreboding is a bit extreme here. I get more node bugs landing in my inbox than probably anyone else on this list. 0.4 is dead. Virtually no one is using it, and the people that ARE using it, are using it specifically because they're not upgrading everything or doing new work. This is not a real concern, and if it ever becomes one, it won't be all that hard to address. On Wed, Jun 27, 2012 at 7:26 PM, Marcel Laverdet <[email protected]> wrote: > If this is a bad problem I feel the correct solution would be > to add a flag to npm install such that you could skip the engines check: > `npm install --force some-legacy-package`. Marcel, the fact that you suggest we "add" this is proof to me that it is insufficient. --force has behaved this way for many months now. > Regarding engines, I'm using it in node-fibers.. "node":">=0.5.2". There are > older versions of fibers that work with older versions of node, and those > are also marked correctly in their metadata. The current version of npm requires node 0.6, and breaks super badly on node 0.4. So really, this is a question about how node will change moving forward. (New thread coming soon, regarding our stance on future api breakage, stay tuned.) If it causes massive problems, we can just revert it. It's not THAT big of a deal. The main issue is that `npm init` was for several versions too restrictive about the defualt "engines" value, and people didn't even realize that they were making work for themselves in the future. (And in nodes <=0.4, it was a much greater need to specify the working engine precisely.) Since I removed a default engine from `npm init`, most people don't even use it, and it's usually just a silly reason to not upgrade. -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
