atom / apm Goto Github PK
View Code? Open in Web Editor NEWAtom Package Manager
Home Page: https://atom.io/packages
License: MIT License
Atom Package Manager
Home Page: https://atom.io/packages
License: MIT License
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?
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
??
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...)
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.
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?
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
Upgrades all out of date packages
Make sure the tag is available from the GitHub API before telling atom.io about the new release.
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' } ] }
Currently assumes /Applications/Atom.app
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?)
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:
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 precompile .coffee
and .cson
files when publishing for a faster experience when people install packages.
This should be kicked off by the atom build when atom-shell is upgraded to recompile native modules against the latest headers.
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.
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 I type apm dev autosave
it downloads the autosave node module instead of the autosave atom package.
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
.
Needs a package.json
instead of package.cson
and should have more default fields such as name, version, description, etc.
Very common flow
Make sure no package anywhere in the dependency tree is referencing top-level modules before cleaning them out.
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.
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?
Clone the package to ~/github
Link to ~/.atom/dev/packages
Add option to clone and link all atom packages from ~/github/atom/package.json
[master] ~/.atom/packages/emmet $ apm publish 0.1.4
Preparing and tagging a new version ✓
Pushing v0.1.4 tag ✓
Publishing [email protected] ✗
Creating new version failed: Git tag not found
[master] ~/.atom/packages/emmet $ git tag
v0.1.0
v0.1.1
v0.1.2
v0.1.3
v0.1.4
[master] ~/.atom/packages/emmet $ apm publish -t v0.1.4
Publishing [email protected] ✗
Creating new version failed: Git tag not found
[master] ~/.atom/packages/emmet $ apm -v
0.7.0
Runs the specs from the current package in a window and then quits
It reports tests as passing when they fail, not sure why yet.
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.
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
[daniel@lilcomps apm ((v0.32.0))]$ ./node_modules/grunt-cli/bin/grunt prepublish
Running "clean" task
Running "node" task
Fatal error: incorrect header check
[daniel@lilcomps apm ((v0.32.0))]$
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
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
This will allows the snippets package to expect only a single snippet format and make all snippets consistent.
Because come on I am lazy.
https://github.com/github/gitignore/blob/master/Node.gitignore
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
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.
Allow available output that contains only themes in it.
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.
Now that we are on releases instead of ☁️ 🐜 we can stop using our custom npm fork that supports multiple registries
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:
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 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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.