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
