Forum > Third party

Online Package Manager

<< < (2/440) > >>

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

Go to full version