Forum > Third party

Online Package Manager

<< < (4/438) > >>

GetMem:
@rvk
You're the first one who actually tested the pacakge, thank you for this!

--- Quote ---TJSONStringType is an UTF8String in trunk.
--- End quote ---
Fixed! I should have typed "AJSON: TJSONStringType" instead of "AJSON: Ansistring"

--- Quote ---Suggestion #1: Making the packages-list more compact. Only expanding when choosing the +
--- End quote ---
Done. I updated the link.

--- Quote ---Suggestion #2: Putting the "Online Package Manager" above the "Install/Uninstall packages". I'm very used to be "Install" being the last in that menu :) Although, if this becomes the standard the position at the bottom might be preferred.
--- End quote ---
I will leave it where it is for now, since we are only testing. It can be changed later if necessary.

--- Quote ---Question: What packages will be provided in the end.
--- End quote ---
Every package will be accepted in the official repository with one condition, it must be checked first. I will do the work if necessary.

--- Quote ---Will the lazarus-ccr packages/components be added?
--- End quote ---
Yes.


@Phil, @lainz, @molly, @Graeme

--- 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.
--- End quote ---
I plan to add support for external zip files/repositories, but this is a dangerous game(my only problem with delphinus + the fact, that it force you to use github). The package manager will automatically download/extract the zip, then install it into the IDE. It's a great way to inject a malware into someone's computer. This is why I insist to have an official repository, where the packages can be checked(malware wise + legally as @Phil mentioned). On the other hand, forcing the developers to use only the packages from the official repository it's also wrong, but they must use it at their own risk.


@howardpc
I was hopping that the official repository can be hosted in one of the freepascal.org directory(see fppkg). For now @Leledumbo was kind enough to host the repository on his personal server.

PS: Thank you all for the feedback.

Phil:

--- Quote from: GetMem on October 05, 2016, 09:19:56 pm ---Every package will be accepted in the official repository with one condition, it must be checked first. I will do the work if necessary.

--- End quote ---

That sounds reasonable.


--- Quote ---I was hopping that the official repository can be hosted in one of the freepascal.org directory(see fppkg). For now @Leledumbo was kind enough to host the repository on his personal server.

--- End quote ---

It might actually be healthy to be independent of freepascal.org.

In any case, since you guys are doing the work, it's up to you to decide where to host it. Leledumbo's server sounds fine to me.

JuhaManninen:
Sorry I haven't tested the package manager yet. I try to do it soon, today or tomorrow.
Earlier discussions have recommended fppkg.
 http://free-pascal-lazarus.989080.n3.nabble.com/Lazarus-An-online-package-manager-tt4043469.html#none
I discussed with GetMem earlier and he says fppkg is not very well suited here. I must take his word on this issue because he is the only person so far to make a functional online package manager.
"Lazarus packagemanager" from Darius Blaszyk uses fppkg but does not work.
The "Aarre" initiative from Mattias and myself has no functional code either.
Several people (including myself) had plans to write such a package manager ... but nobody did until now.

My goal is to include this GetMem's work in Lazarus sources, either as a package or directly in the packages/ source directory.
It also means commit access for him.
It does not need to be perfect initially. As always a piece of code improves by iterations. People can then provide patches to improve it.
Using / not using fppkg is a big design decision but even that can be changed if need be. But again, it needs code from somebody. Simply expressing one's opinion on the issue is not enough.

The management of online packages and the packages included with Lazarus must be integrated seamlessly. Dependencies between all them must be handled automatically.
However this is not required in the initial version either.


--- Quote from: Graeme on October 05, 2016, 08:02:30 pm ---The best approach seems to be whan  Delphinus does on Github. Everything is hosted there.  Delphinus use the Github API to detect new packages and automatically present those in the IDE.

--- End quote ---

Ok, I was planning to ask how it scans all the projects to find Delphi packages. I guess it searches a specific file name using the Github API.
Yes, that is cool and tempting but it must not be the only interface for our package manager. We must support other sources, too. Some packages (Lazarus CCR) are in SourceForge and there are various other options.
So, support for Github API and other APIs should be added later but not initially.

I will answer the Lazarus mailing list post after I have tested the package manager. Please follow it, too.
Talking about mailing list, does it work now for everybody? The known problems were solved by Marc.

JuhaManninen:

--- Quote from: GetMem on October 05, 2016, 09:19:56 pm ---I plan to add support for external zip files/repositories, but this is a dangerous game(my only problem with delphinus + the fact, that it force you to use github). The package manager will automatically download/extract the zip, then install it into the IDE. It's a great way to inject a malware into someone's computer. This is why I insist to have an official repository, where the packages can be checked(malware wise + legally as @Phil mentioned). On the other hand, forcing the developers to use only the packages from the official repository it's also wrong, but they must use it at their own risk.

--- End quote ---

A user must not need to learn other alternative URLs for packages, nor copy/paste them. The user must be able to simply search for packages by name + other criteria and get a list of all worthy packages.
It means your JSON config must support an external URL. It should be a trivial change (ok, I write this without testing your code yet).
It means a package author can make the required ZIP file in his repository and ask you to add it to the list. Files don't need to be copied anywhere.
Do SourceForge etc. allow direct download links for files? I think they do. I remember you claimed the opposite. I must study the issue.
Testing your code is now nro 2. in my ToDo list. Wait ...

JuhaManninen:

--- Quote from: Phil on October 05, 2016, 07:16:43 pm ---(1) Package must have a proper license. If it's the same as LCL or FPC RTL, just state so or point to the FPC modified LGPL doc files. If it's something else, anything, just have a link to it (Eclipse, BSD, etc.). The only thing unacceptable might be if nothing is specified in the JSON file. By clearly stating what license is used, the user of the package manager can decide beforehand whether that's even a package they're interested in.

--- End quote ---

An "official" server with a managed configuration file solves the issue. Only legal packages are accepted.
Otherwise the license does not matter, any free package is OK. The license can be commercial, for example if a company wants to deliver a demo of their product, fine. It is not a package manager's task to decide.
The license should be shown in the GUI, yes.


--- Quote ---(2) If the package depends on LCL (ie, has LCL under RequiredPgks in .lpk file), then it must specify what LCL interfaces it has been tested against. I typically test against Carbon, Win32, GTK2 at a minimum so that I can legitimately say that the package is cross-platform.

--- End quote ---

Yes, that information must be shown, too. There are packages which cannot be cross-platform by definition, for example by using MS Office tools by OLE automation.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version