Apm problem when publishing package


#1
~/.atom/packages/block-travel[master]% apm publish tiny
Preparing and tagging a new version ✗

npm ERR! npm version [<newversion> | major | minor | patch]
npm ERR!
npm ERR! (run in package dir)
npm ERR! 'npm -v' or 'npm --version' to print npm version (1.3.18)
npm ERR! 'npm view <pkg> version' to view a package's published version
npm ERR! 'npm ls' to inspect current package/dependency versions
npm ERR! not ok code 0

This only started happening when upgrading to 0.61.0, everything worked fine before.


#2

Hah, I meant to use apm publish minor. Maybe the outcome of this is that the error message is improved. Thanks!


#3

Damn even using apm publish minor I got same error:

Preparing and tagging a new version ✗
npm ERR! npm version [<newversion> | major | minor | patch]
npm ERR! 
npm ERR! (run in package dir)
npm ERR! 'npm -v' or 'npm --version' to print npm version (1.4.4)
npm ERR! 'npm view <pkg> version' to view a package's published version
npm ERR! 'npm ls' to inspect current package/dependency versions
npm ERR! not ok code 0

#4

Turns out that your version in the package.json needs to be 0.0.0 I changed mine from 0.1.0 to 0.2, and cause the error, I changed it to 0.0.1 and then it made an upgrade to 0.2.0


#5

I personally find the --tag option to be the simplest with the most control. I was constantly screwing things up otherwise.


#6

On the most control, I definitely agree. I have to disagree with the “simplest” part of that statement though :grinning: If you let apm manage the version number, it is very simple. Just remember that the major, minor and patch subcommands update the version number according the SemVer standard.


#7

There is a problem in publish that it doesn’t handle errors well. When I was trying to publish the first time I was lucky enough to have done everything wrong possible. My version count neared 20 more than it was supposed to be.

So by the simplest I meant the most fool-proof. Just think of the right version in your head and use it everywhere. Then publish that number with --tag. What could be simpler.

It’s also simple because you don’t have to understand the version bumping system. That bumping is magic that isn’t needed.


#8

I used to hold this same idea … that magic should be avoided. But, the thing is that at some level (unless you understand absolutely everything all the way down to the intimate details of the processor design, branch prediction, etc) the things that we do are going to be magic. This is what abstractions are about. If I do X then Y happens. If I add one and one I get two. A for loop works the way we expect even if the compiler unrolls the loop behind the scenes. Is it sometimes helpful to know that the loop is unrolled? Sure. But in the main case we can just deal with the abstraction … the magic that we’ve come to be so familiar with that it is second nature.

The admonition against magic is really just distrust of new magic :wink:


#9

That is an amazing argument you have there. Since everything is magic then there is no need to have the concept of magic. You have just destroyed a very useful concept. Shame on you. :smile:

What makes something magic is when the effort required to understand a behavior is greater than a person (and it is different for different people) can handle. And by greater than I mean to include “more trouble than I want to handle”.

So I argue that the concept of magic applies and is a valuable thing to consider when doing UI design.


#10

Absolutely! As a matter of fact, I’m a big fan of the book About Face where they spend a lot of time talking about “physical models” versus “mental models” and how to provide a proper abstraction that helps the user rather than hinders them. And, honestly, I’d rather use that terminology than the loaded term “magic” in these kinds of discussions because that’s what we’re really discussing. The argument against “magic” is the argument that physical models are always or almost always better than mental models. Where that breaks down is when the physical model forces someone to learn something that they don’t need to learn in order to get their task done. File systems are a great example. Arguably one of the major reasons why smartphones and tablets have become so popular is because they do not force the typical user to deal with a file system (which the typical user doesn’t take the time to understand and thereby runs into problems like “Where did my file go? I just saved it!”)

Now, that is for the “typical” user (average user, Joe/Jane User, whatever you want to call it). But what about your situation? What about when you run into a user where they have invested the time so that their mental model is equivalent to the physical model? (Or at least “equivalent enough”, of course.) Then providing an abstraction that offers a different mental model than the physical one can be a hindrance … as you rightly pointed out. But the right thing there is not to do away with the mental model completely … the right answer is to provide the obviously advanced user a way of doing the advanced things they want to do by offering trap doors to access the physical model, i.e. the --tag option.

What I’m really saying is that just because you’re an advanced user doesn’t mean that you should take away the features that make life simpler for the people that aren’t as advanced as you. As a matter of fact, having those simplified mental models or abstractions in place gives people an easier ramp into becoming an advanced user over time.


#11

An aside – I’m the one to which --minor seems like magic. I have no desire to learn that magic. (Well, it also has a lot to do with the APM bug).

Anyway, I agree with you 100%. I didn’t argue to force --tag on users. I just think it is the best way to start a beginner and they can move on to the magic when they are more ready for it. Hence my suggestion to the OP to use --tag


#12

That is my view, as well. Most software is developed with end users in mind. Whether you call it magic, black box behavior, or what have you… in the end you want the vast majority of car drivers to have access to the steering wheel, not so much to the oil pump.

Techies need special, enhanced access (especially on a product that labels itself “the hackable X”, no doubt). But no magician shows the audience the inside of his sleeve, only to his crew behind the stage.
Not because it would ruin the experience, but because they simply don’t want to have to know how it works and that… well, that’s the magic, isn’t it. :wink:


#13

Fix the apm bug and this becomes a non-issue.