Forum > Third party
Online Package Manager
Phil:
--- Quote from: rvk on October 05, 2016, 04:15:22 pm ---(That would also allow you to make your own repository in addition to the default ones provided)
--- End quote ---
I would assume this would be the case. That way, a package author only needs to publicize the URL of the package zip. The user types/pastes this URL into the package manager, which does the rest.
I would use a separate .zip for each package. And each .zip would contain its own JSON file for the package. Put a master list of packages elsewhere.
Take a look at how this is implemented in other IDE/apps. For example, QGIS has supported Python plugins for years and has hundreds of plugins to manage. Look at the QGIS External (official) and Experimental plugins dialogs here:
http://www.qgistutorials.com/en/docs/using_plugins.html
Note that official plugins need to be approved. Here's their list of items to pay attention to for fast approval:
http://plugins.qgis.org
lainz:
I agree with Phil, so for example I can upload a release on GitHub that in fact is a package, and then anyone can just copy and paste the URL to this program and get the package installed.
Phil:
Exactly. The only question in my mind is whether there should be any sort of "official" stamp, or perhaps just a requirement that the package have an appropriate license (modified LGPL, for example), documentation, etc. as indicated by the contents of the JSON file.
howardpc:
Apart from questions of improving the functionality, reliability, security etc. of the package manager, careful thought needs to be given to non-software issues such as long term funding of webserver costs, who (or what grouping) has control of the 'official' repositories, what are the criteria for inclusion/rejection of submitted packages, whether some PPA-type system should be in place for addition of private repositories, who will police it in terms of enforcing adherence to the stated policies, and so on.
This is a bold start, but there could be a minefield ahead in terms of future maintenance and oversight, not so much of the software itself, but of the data it manages and the ongoing quality of that data.
lainz:
If money is an issue I recommend to host it on GitHub/Sourceforge that has free website that is managed with a repository/ftp for project or organization.
Use standard releases for each package and only mantain a list of json that points to another url where the real zip is available (the zip can be in any host service).
If you choose GitHub/Sourceforge you can add as many mantainers you want, simple give them access to put files in the website.
Navigation
[0] Message Index
[#] Next page
[*] Previous page