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 <mar...@laverdet.com> 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 <i...@izs.me> wrote:
>>
>> On Thu, Jun 28, 2012 at 6:10 AM, Matt <hel...@gmail.com> 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 <vit...@rcdesign.ru>
>> 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 <mar...@laverdet.com>
>> 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 nodejs@googlegroups.com
>> To unsubscribe from this group, send email to
>> nodejs+unsubscr...@googlegroups.com
>> 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 nodejs@googlegroups.com
> To unsubscribe from this group, send email to
> nodejs+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
--
Joshua Holbrook
Engineer
Nodejitsu Inc.
j...@nodejitsu.com
--
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 nodejs@googlegroups.com
To unsubscribe from this group, send email to
nodejs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
