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/ee1d168d7a4798b67bb9a7667b5ec93a8be3d953 > 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/ee1d168d7a4798b67bb9a7667b5ec93a8be3d953 > 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/ee1d168d7a4798b67bb9a7667b5ec93a8be3d953 > 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 > -- 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
