The problem is clearly that npm tries too hard to install older versions than the most recent one. That's the bug here. Just try and install the most recent one and fail hard if it doesn't match the requirements and if --force isn't set.
On Thu, Jun 28, 2012 at 7:55 PM, Joshua Holbrook <[email protected]>wrote: > I think part of the issue is that node is maturing faster than people > thought it would. > > --Josh > > On Thu, Jun 28, 2012 at 4:45 PM, Marcel Laverdet <[email protected]> > wrote: > >> 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. > > > > If the flag already existed, why not add a tip to the ENOTSUP failure? If > > the only thing that is broken is user education, then why not add > education > > right when the user needs it? > > > > --- a/lib/utils/error-handler.js > > +++ b/lib/utils/error-handler.js > > @@ -202,7 +202,8 @@ function errorHandler (er) { > > ,"Required: "+JSON.stringify(er.required) > > ,"Actual: " > > +JSON.stringify({npm:npm.version > > - ,node:npm.config.get("node-version")}) > > + ,node:npm.config.get("node-version")}), > > + "If you want to try anyway, please use > the > > --force flag to skip this check." > > ].join("\n")) > > break > > } // else passthrough > > > > > >> 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. > > > > You're right, it isn't that big of a deal on it's own.. My concern here > is > > that this is a permanent solution to a temporary problem and is a culture > > not really healthy to long-term software development. It seems Node has > > always been of the mindset "maintain your shit or it may stop working in > the > > future", at least until the platform is more mature. This is a new flag > > everyone has to be aware of now. Reading the documentation for "engines" > now > > everyone will have to read and understand "enginesStrict" for the rest of > > time. > > > > It reminds me of how in PHP, E_ALL doesn't actually mean "all errors". > You > > have to do `E_ALL | E_STRICT` if you *really* want all errors. Or how > after > > they created `mysql_escape_string` they realized it didn't work correctly > > non-latin1 charsets and had to add `mysql_real_escape_string`. > > > > I know there are concerns of adoption of new versions of node, but cruft > is > > never a good thing to add. > > > > On Thu, Jun 28, 2012 at 2:33 PM, Isaac Schlueter <[email protected]> wrote: > >> > >> 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 > > > > -- > Joshua Holbrook > Engineer > Nodejitsu Inc. > [email protected] > > -- > 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
