Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Public repositories #75

Open
6 of 9 tasks
polyvertex opened this issue Jul 1, 2016 · 3 comments
Open
6 of 9 tasks

Public repositories #75

polyvertex opened this issue Jul 1, 2016 · 3 comments

Comments

@polyvertex
Copy link
Member

@polyvertex polyvertex commented Jul 1, 2016

Having public repositories would allow Keypirinha to be more community-oriented and would allow contributors to correct and improve the shipped packages as well as the documentation.

  • Create an official package file structure (e.g. manifest file), so third-party plugins could be referenced from a centralized place (e.g. auto install directly from Keypirinha)
  • Write some guidelines to document this structure
  • Create a separate public repository for the shipped python site modules (i.e. keypirinha.py, keypirinha_util.py, ...)
  • Create a separate public repository for the official packages
  • Create a separate public repository for the documentation
  • Craft a new release-builder script that integrates these changes
  • Add network support to global configuration and the plugin API eventually (see #74)
  • Create a plugin SDK in a public repository (see #76)
  • Reference third-party plugins so users and Keypirinha can easily list them

Something I forgot?

@psistorm
Copy link

@psistorm psistorm commented Jul 5, 2016

Although I'm pretty sure you have had thoughts in that direction, I wanted to mentioned something:
Regarding the first bullet point (official package file structure) I would also suggest some sort of version handling for the plugins, so the user is easily able to identify which plugin version he uses and in direction of auto install from Keypirinha also able to determine whether a plugin needs an update or not.
One idea could be to use the github REST API. If every plugin is placed inside a github repository which is linked in the manifest file, you can use the REST API from github to compare the internal manifest version with the latest release on github

Loading

@polyvertex
Copy link
Member Author

@polyvertex polyvertex commented Jul 6, 2016

I have planned to allow package versioning through the manifest file indeed. Mainly for manual check-up at the beginning. The automation of the install and update of packages will come later unfortunately. It's a matter of priority in the todo list. That being said, I hadn't thought of taking a look at the GitHub API so far so I'll keep that in mind. It was worth mentioning it, thanks!

Loading

@polyvertex
Copy link
Member Author

@polyvertex polyvertex commented Sep 17, 2016

Update: SDK and Packages repositories are both online and open to contributions.

Loading

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants