I think the only reason APM needs a token from the keychain is because Atom.io and the Atom org are private. All other operations can be done via git and the command line (like publish is).

If we hardcode a token into APM until we release it would solve the problems like @benogle was having in #33.

apm help publish says:

Run apm available to see all the currently published packages.

But running 'apm available' says there isn't a command named that.

From: support/900c86069f8411e38436c4102e33f055

Do we have a nice way to rename a package so that it doesnt break for current installs? I really want to tell people to rename their syntax themes (and rename a couple of ours, mac-ui, base16-tomorrow-dark, monokai). Also if folks want to rename for any other reason, it seems they cant.

apm mv? apm rename??

For various reasons, we need to discontinue the use of a GitHub OAuth
token with the Atom.io API. This is a little awkward as there are a number of
moving parts: The atom.io site/account page, the API, apm, and Atom's apm integration.

Here's one way we could do this, feedback requested:

• Finish up the branch with the atom.io account page and deploy it behind a staff-only feature flag.
• Get a branch of apm going with twitter cli-style auth flow (#82)
• Confirm the editor doesn't make any authed API calls directly.
• Remove GitHub OAuth token from all public API calls in Atom (I think these all shell out to APM anyway)
• Ship apm with new auth flow and genpop account page
• Solve apm authentication flow in Atom itself when the need presents itself (e.g. for auto-update should we decide to charge)
• Leave GitHub OAuth support in until enough active users have upgraded their editor and we've blogged about it.

This maybe seems like a lot of steps but it's not so bad, and it's transparent
to the everyday user. The only people that even need to know about the change
are package publishers, of whom there are only 710 (less than 1% of users)

I'm filing this issue on atom/apm because the biggest change to any of the
software involved is to add a "copy-paste from the web" flow to apm's
authentication / authorization.

I published a private repo to apm today and apm reported everything as a-ok. I could even see my package on atom.io. Then when someone tried to install it, it failed because my repo was private. It would be rad if apm would prevent me from publishing if the source repo is private.

Rather than just die if the GitHub API Token keychain token is not found, it should ask you to login to your github acct, and store the token in the GitHub API Token.

This should be kicked off by the atom build when atom-shell is upgraded to recompile native modules against the latest headers.

Example:

I have fuzzy-finder checked out, but it is WAY behind. In fact, I forgot I even had it installed locally.

So when I run apm dev fuzzy-finder I expect it to be using the most recent version. It might be too aggressive or complicated to force update fuzzy-finder. But it would be nice if it had a warning that it wasn't on origin/master

Moving this from atom/atom#1035

So we currently reference the security command here src/auth.coffee

@zcbenz has opened atom/node-keytar#3, so we can replace security -q find-generic-password -ws 'GitHub API Token' with require('keytar').findPasswordForService('GitHub API Token')

On Windows ideally we should be able to get the access token from GitHub's Windows client, but @paulcbetts mentioned that Github for Windows can't use the Windows Vault due to backwards compatibility.

Given all of that, I think it still makes sense to move forward with this change because atleast if they've signed in with Atom, we can reuse that key. For initial users I think we should just suggest that they bootstrap using an environment variable. Thoughts?

apm should be the home of things like AtomPackage, Package, and much of the package related code in the atom global. These currently still sit in the atom/atom repository. Also there is a PackageManager class in atom/settings-view that should probably be pulled in as well into apm.

Pull these out once atom/atom#775, atom/atom#778, and atom/atom#787 land.

Upgrades all out of date packages

Runs the specs from the current package in a window and then quits

If I type apm dev autosave it downloads the autosave node module instead of the autosave atom package.

If you have a wrong URL in your repository field when setting up a plugin, you'll get this back from apm:

Registering package failed: That repo does not exist, isn't an atom package, or you do not have access

It would be nice if the error message included what that wrong repo was just to be extra clear since people seem to forget to set it correctly and get confused. (From the IRC channel...)

https://github.com/atom/apm/blob/cdfc4ffd019c61cfece2dafb7a9a12ea01bdb520/templates/package/keymaps/__package-name__.cson.template

I think the problem is that it's using meta and it looks like keymaps are headed in a more OS-specific direction. I was going to PR something up, but I realized I had no idea what we want to teach people in this example file.

Needs a package.json instead of package.cson and should have more default fields such as name, version, description, etc.

I get this when running apm:

$ apm version 

/Applications/Atom.app/Contents/Resources/app/node_modules/keytar/node_modules/bindings/bindings.js:83
        throw e
              ^
Error: Module version mismatch. Expected 11, got 13.
    at Module.load (module.js:356:32)
    at Function.Module._load (module.js:312:12)
    at Module.require (module.js:364:17)
    at require (module.js:380:17)
    at bindings (/Applications/Atom.app/Contents/Resources/app/node_modules/keytar/node_modules/bindings/bindings.js:76:44)
    at Object.<anonymous> (/Applications/Atom.app/Contents/Resources/app/node_modules/keytar/lib/keytar.js:4:31)
    at Object.<anonymous> (/Applications/Atom.app/Contents/Resources/app/node_modules/keytar/lib/keytar.js:58:4)
    at Module._compile (module.js:456:26)
    at Object.Module._extensions..js (module.js:474:10)
    at Module.load (module.js:356:32)

I'm on Atom v0.64.0, and ran the install cli tools command.

See atom/atom-dark-ui#15

What's the story for actually contributing to a 3rd party package installed via apm develop? It just clones from the repo url, but doesn't make a fork. This works for us, but not those without commit bit. Could it fork and clone?

We should at least have some docs on how we think they should do it (fork, then change the origin after apm develop?)

http://discuss.atom.io/t/submitting-a-pull-request/2306

What's the story for deprecating a package? Say I am no longer developing my package, and I want to point to someone else's package.

The easiest thing is obviously putting something in the readme that points to another package. But deprecation would not be shown in the settings view unless the readme button were explicitly clicked.

I dont know where to put this, so it's near the package stuff.

Whenever I see a new update to a package, I want to know wtf changed. So now, my process is to head to the repo and look through the commits between 'prepare x.x.x' commits. Not ideal.

How would you feel about encouraging a CHANGELOG.md with a specific format, and parsing/displaying it in the settings? It's manual for them, but we could probably get most to use it juts by encouraging in the docs. Maybe apm could even look for an entry in the changelog for the version to be published and warn if there is nothing for that version. eg.

$ apm publish minor
Warning: You do not have an entry for v0.5.1 in the CHANGELOG.md. Sure you want to continue?

Yar? Nar? Too complicated?

Interesting suggestion via email: The guy suggests disallowing atom- package name prefixes. I think a gentle message could be a better choice.

Feel free to close this issue, but thought it was a good enough idea to warrant one.

If you run apm init --package something a .npmignore file is created but no .gitignore file. This is odd because in apm's template directory there is a .gitignore file but no .npmignore file.

Make sure the tag is available from the GitHub API before telling atom.io about the new release.

Currently assumes /Applications/Atom.app

Because come on I am lazy.

https://github.com/github/gitignore/blob/master/Node.gitignore

This will allows the snippets package to expect only a single snippet format and make all snippets consistent.

It should be fixed when the language repos are fixed. Here's all the places it's misspelled: https://github.com/search?q=repitition+user%3Aatom&ref=searchresults&type=Code

ref atom/language-ruby#1

It reports tests as passing when they fail, not sure why yet.

Make sure no package anywhere in the dependency tree is referencing top-level modules before cleaning them out.

We should precompile .coffee and .cson files when publishing for a faster experience when people install packages.

Now that we are on releases instead of ☁️ 🐜 we can stop using our custom npm fork that supports multiple registries

From a halp ticket

The search page for packages should be drastically improved. Concrete example:

- search for 'prefix' -> nothing
- search for 'autoprefix' -> nothing
- search for 'autoprefixer' => finds the autoprefixer package

Clone the package to ~/github
Link to ~/.atom/dev/packages
Add option to clone and link all atom packages from ~/github/atom/package.json

On Windows though it's possible to create symbols links, but it requires the Administrator privilege to do that, or at least requires the Administrator user to grant the permission to normal users, and it's hard to get it right:
http://superuser.com/questions/124679/how-do-i-create-a-link-in-windows-7-home-premium-as-a-regular-user

Maybe we could create file shortcuts instead of symbol links on Windows?

Tried to publish. No worky with master!

Very common flow

So I've noticed apm publish minor seems to randomly fail every other try or so with error message Git tag not found? Re-running seems to usually just work the next time.

Here's the last several tries from my editor, about half of which failed:

Joels-MacBook-Air:fizzy joelglovier$ apm publish minor
Preparing and tagging a new version ✓
Pushing v0.10.0 tag ✓
Publishing [email protected] ✗
Creating new version failed: Git tag not found
Joels-MacBook-Air:fizzy joelglovier$ apm publish minor
Preparing and tagging a new version ✓
Pushing v0.11.0 tag ✓
Publishing [email protected] ✓
Joels-MacBook-Air:fizzy joelglovier$ apm publish minor
Preparing and tagging a new version ✓
Pushing v0.12.0 tag ✓
Publishing [email protected] ✗
Creating new version failed: Git tag not found
Joels-MacBook-Air:fizzy joelglovier$ apm publish minor
Preparing and tagging a new version ✓
Pushing v0.13.0 tag ✓
Publishing [email protected] ✗
Creating new version failed: Git tag not found
Joels-MacBook-Air:fizzy joelglovier$ apm publish minor
Preparing and tagging a new version ✓
Pushing v0.14.0 tag ✓
Publishing [email protected] ✓

apm -v shows I'm on 0.10.0

Auth:

Currently the atom.io package API accepts a valid GH OAuth token in the Authorization header. We store this in the keychain (right?) when a user signs in with Atom, and can use that when shelling out to APM there. What about when running e.g. apm publish from the CLI? Check the keychain for an oauth token and then direct the user to sign in with Atom if it's not present?

Fetching:

This should be straightforward, though the current API diverges slightly from npmjs.org

Publishing:

• If we use the GH tag API for publishing, publish needs to push the tags up to GH before submitting the package. see #22 , API docs linked above.

In a past life I wrote plenty of coffeescript, so I am happy to have a go at spiking out the necessary changes.

Also, the package API is not fully baked as it has no client yet, so feel free to propose changes that will make this smoother.

We should provide a basic set of selectors and use less variables for easy customization (like solarized-dark-syntax).

I think this will solve the majority case where users would like to select different colors but without learning all of our TM grammar syntax classes.

Allow available output that contains only themes in it.

Duplicate notes are no longer allowed:

{ message: 'Validation Failed',
  documentation_url: 'http://developer.github.com/v3/oauth_authorizations/#create-a-new-authorization',
  errors: 
   [ { resource: 'OauthAccess',
       code: 'already_exists',
       field: 'description' } ] }