Capping the low-end is reasonable but yeah I've really given myself more work by using this
On Jun 27, 7:29 pm, Vitaly Puzrin <[email protected]> wrote: > Advisory mode is artificial kludge. Adding new key to config breaks > compatibility & KISS principle. > If someone needs to override conditions, it's common to add option > "--force" or similar to CLI. > > IMHO, in practice, you just fuckuped all packages, that really needed > strong node version dependencies. > I don't know package managers from other languages, who support such logic. > And i don't understand, > why node should resolve situation in another way. > > четверг, 28 июня 2012 г., 5:16:20 UTC+4 пользователь Isaac Schlueter > написал: > > > > > > > > > > > > > Vitaly, > > > In practice, what happens is that a new version of Node comes out, and > > no one can use it until everyone else uses it, which is not great for > > me or for this community. We need to be moving forward. In a lot of > > cases, the metadata was reasonable at the time, and added by `npm > > init`. We encourage the creation of many hundreds of small reusable > > modules every day. We can't then turn around and penalize people for > > using the tools, or expect that they spend lots of time doing boring > > hoop-jumping maintenance. > > > It's done: > >https://github.com/isaacs/npm/commit/ee1d168d7a4798b67bb9a7667b5ec93a... > > Engines is advisory. It prints a warning. Set `engineStrict` in your > > package.json, or `--engine-strict` config, to make it strict. (If the > > package.json field is abused, it will be removed eventually. I don't > > suspect this is going to be an issue.) > > > On Wed, Jun 27, 2012 at 6:09 PM, Vitaly Puzrin <[email protected]> > > wrote: > > > You try to make magic in place, where it is scrictly unwelcome. > > > > Broken metadata is just broken metadata, but not the problem, that > > should be > > > solved in npm. > > > If package is not updated for ages and has wrong dependencies - just let > > him > > > die. > > > > среда, 27 июня 2012 г., 21:45:51 UTC+4 пользователь Isaac Schlueter > > написал: > > > >> Thanks for the feedback, everyone. > > > >> It seems like we can achieve the optimum balance like this: > > > >> 1. add an "engines-strict" config, default false > > >> 2. If "engines-strict" == true, then the current behavior. > > >> 3. if "engines-strict" == false, then it's a warning > > > >> Then Heroku and Azure and the like can set the flag in their envs if > > >> they want to (or just look at the engines value and do whatever they > > >> want with it), and users will be alerted about the need to upgrade > > >> (but without being forced to, or as is more often the case, forced NOT > > >> to.) > > > >> Adding checking for "or higher" would seem to be too subtle a change > > >> to me. Ie, if your package says `"engines":"0.4.x"`, and I have node > > >> 0.8, do you *really* mean >=0.6.0? Or do you mean that you rely on > > >> listenFD, which is gone in 0.6, and reimplemented in 0.8, but somewhat > > >> differently? > > > >> It seems like the better option is just to warn you that it might > > >> break, and then let it break. > > > >> Another option might be to let authors add an "enginesStrict" boolean > > >> flag in their package.json which would say, "No, seriously, this WILL > > >> NOT WORK except with the specified versions, so don't even try to use > > >> it." > > > >> What we're seeing in practice is just weird and broken behavior, > > >> usually because an old version of something (say, a package from 2 > > >> years ago, which doesn't work on modern node) might have no engines > > >> specified, but a newer version of the same package (which works fine > > >> on 0.8) has "engines":{"node":"0.6.x"} specified. So, npm tries to > > >> find the most recent version that it thinks will work, and it gets > > >> 0.1.2 (which is broken and old) instead of 4.8.12 (which is new, and > > >> works). That's the opposite of the intent. A nag would be more > > >> appropriate in that case, I think. > > > >> On Wed, Jun 27, 2012 at 8:50 AM, Glenn Block <[email protected]> > > >> wrote: > > >> > We were just about to take a dependency on it for Azure. Is there an > > >> > alternative recommended approach? I believe Heroku uses this as well. > > > >> > Sent from my Windows Phone > > >> > ________________________________ > > >> > From: Bradley Meck > > >> > Sent: 6/26/2012 10:09 PM > > >> > To: [email protected] > > >> > Subject: [nodejs] Re: remove "engines" from package.json? > > > >> > At least some PaaS use it. I think it it were tied to tests in some > > way > > >> > it > > >> > would be more meaningful for the average user, but for now it most > > >> > commonly > > >> > used for PaaS deploys. > > > >> > On Wednesday, June 27, 2012 12:06:52 AM UTC-5, Isaac Schlueter wrote: > > > >> >> Do people actually rely on the "engines" hash being respected in npm > > >> >> installs any more? It was super essential in the early days when > > the > > >> >> API was changing constantly, but now, it seems like it just makes it > > >> >> unnecessarily difficult to upgrade stuff. > > > >> >> If no one is relying on this right now, I'm going to reduce it to a > > >> >> warning. If in time, people start complaining that the warning is > > to > > >> >> warny, we can remove it, and just let "engines" be a thing of the > > >> >> past. (Note that `npm init` already doesn't bother with it, and for > > a > > >> >> while has just defaulted to {"node":"*"}.) > > > >> >> Please let me know what you think. Thanks :) > > > >> > -- > > >> > 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 > > > > -- > > > 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 > > четверг, 28 июня 2012 г., 5:16:20 UTC+4 пользователь Isaac Schlueter > написал: > > > > > > > > > > > Vitaly, > > > In practice, what happens is that a new version of Node comes out, and > > no one can use it until everyone else uses it, which is not great for > > me or for this community. We need to be moving forward. In a lot of > > cases, the metadata was reasonable at the time, and added by `npm > > init`. We encourage the creation of many hundreds of small reusable > > modules every day. We can't then turn around and penalize people for > > using the tools, or expect that they spend lots of time doing boring > > hoop-jumping maintenance. > > > It's done: > >https://github.com/isaacs/npm/commit/ee1d168d7a4798b67bb9a7667b5ec93a... > > Engines is advisory. It prints a warning. Set `engineStrict` in your > > package.json, or `--engine-strict` config, to make it strict. (If the > > package.json field is abused, it will be removed eventually. I don't > > suspect this is going to be an issue.) > > > On Wed, Jun 27, 2012 at 6:09 PM, Vitaly Puzrin <[email protected]> > > wrote: > > > You try to make magic in place, where it is scrictly unwelcome. > > > > Broken metadata is just broken metadata, but not the problem, that > > should be > > > solved in npm. > > > If package is not updated for ages and has wrong dependencies - just let > > him > > > die. > > > > среда, 27 июня 2012 г., 21:45:51 UTC+4 пользователь Isaac Schlueter > > написал: > > > >> Thanks for the feedback, everyone. > > > >> It seems like we can achieve the optimum balance like this: > > > >> 1. add an "engines-strict" config, default false > > >> 2. If "engines-strict" == true, then the current behavior. > > >> 3. if "engines-strict" == false, then it's a warning > > > >> Then Heroku and Azure and the like can set the flag in their envs if > > >> they want to (or just look at the engines value and do whatever they > > >> want with it), and users will be alerted about the need to upgrade > > >> (but without being forced to, or as is more often the case, forced NOT > > >> to.) > > > >> Adding checking for "or higher" would seem to be too subtle a change > > >> to me. Ie, if your package says `"engines":"0.4.x"`, and I have node > > >> 0.8, do you *really* mean >=0.6.0? Or do you mean that you rely on > > >> listenFD, which is gone in 0.6, and reimplemented in 0.8, but somewhat > > >> differently? > > > >> It seems like the better option is just to warn you that it might > > >> break, and then let it break. > > > >> Another option might be to let authors add an "enginesStrict" boolean > > >> flag in their package.json which would say, "No, seriously, this WILL > > >> NOT WORK... > > read more >> -- 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
