Online Package Manager

[minesadorada]

So, if an FTP server is set up, and there is a public area for new package uploads (which would be subject to approval) - why not a password-protected 'updates' area for developers who already have approved packages?

To update a package, just ftp the zip and json file to the protected 'updates' area.  No need for external zips with such a simple system.

In the meantime, OPM (Or a separate cron maintenance app) regularly and automatically checks the protected area (just the jsons, so not too heavy) and if it finds a newer version number for an existing package, it transfers the zip to the OPM server and deletes it from the FTP 'updates' area.

This would make maintenance of existing packages a breeze for both devs and the OPM manager.  A weakness is that it would rely on devs not producing a 'bad' update which would propagate to the main server, but it is probably OK because otherwise it means the maintainer has to approve all updates as well as new stuff, which seems unnecessary work.

The only manual maintenance of OPM would be vetting new packages.  Once approved, the dev gets r/w access to the protected 'updates' ftp directory and ongoing maintainence is then up to the dev.

A viable system?

Whatever system is adopted, I have a point update to CryptINI (v0.0.9) ready to test whatever is decided.

On a different note, is Lazarus svn trunk no longer synchronised? I get revision 41451 from the svn server (with no OPM)

[lainz]

You downloaded from sourceforge that is not updated anymore

Download from here
http://svn.freepascal.org/svn/lazarus/trunk

[minesadorada]

You downloaded from sourceforge that is not updated anymore

Download from here
http://svn.freepascal.org/svn/lazarus/trunk

Thanks.

[minesadorada]

An older post in this thread:

Download New version from above link
Went to install package and get error
opkman_installer.pas(166,40) Error: identifier idents no member "DoCompilePackage"

in line

Code: Pascal  [Select][+][-]

1. function TPackageInstaller.CompilePackage(const AIDEPackage: TIDEPackage;
2.   APackageFile: TPackageFile): Integer;
3. begin
4.   Result := -1;
5.   {$if declared(lcl_version)}
6.    {$if (lcl_major >= 1) and (lcl_minor >= 7)}
7.      //DoCompilePackage function is only available with Laz 1.7 +
8.      DoOnPackageInstallProgress(imCompilePackage, APackageFile);
9.      Result := PackageEditingInterface.DoCompilePackage(AIDEPackage, [pcfCleanCompile, pcfDoNotSaveEditorFiles], False);  <--------- HERE
10.    {$endif}
11.   {$endif}
12. end;            

This error is still there.  (Downloaded from trunk)

I have found that with the combination fpc 3.1.1 + Laz 1.7

Code: Pascal  [Select][+][-]

1. {$if something >= somethingelse}

doesn't work. I don't know if it's a bug or intentional.

It only seems to accept

Code: Pascal  [Select][+][-]

1. {$if something > somethingelse}

or

Code: Pascal  [Select][+][-]

1. {$if something < somethingelse}

The fix is:

Code: Pascal  [Select][+][-]

1. {$if (lcl_major > 0) and (lcl_minor > 6)}

[minesadorada]

I'm all over this thread today!

Yet another suggestion:

In the new OPM Options/Folders page, How about the defaults in the Tedit:
Local Repository: {$I LazarusDir}\components
Archive Directory: GetTempDir
Update Directory GetTempDir

[balazsszekely]

@minesadorada
About the fpc 3.1.1 bug: It's weird that ">=" is not supported. I applied your suggestion in r.53428 since logically it's the same as the old one. Thanks!

About the folder page: There is a default value for each folder, just press the "Restore Defaults" button, or delete the config file. You need to do this once, since I recently changed the config file structure.

About the update feature: The "external json" seems more easier to implement. I believe I found a solution, we can keep the central repository and update the packages from external json. I need 1-2 days to implement the feature.

[wp]

I do understand the Local Repository folder, but what are the Archive and Update directories for?

[minesadorada]

@minesadorada
About the fpc 3.1.1 bug: It's weird that ">=" is not supported. I applied your suggestion in r.53428 since logically it's the same as the old one. Thanks!

About the folder page: There is a default value for each folder, just press the "Restore Defaults" button, or delete the config file. You need to do this once, since I recently changed the config file structure.

About the update feature: The "external json" seems more easier to implement. I believe I found a solution, we can keep the central repository and update the packages from external json. I need 1-2 days to implement the feature.

Keep with it @Getmem!  I am relying on the team's brains and expertise

Please review all of this thread regularly for all suggestions and failures.

[balazsszekely]

@wp
I do understand the Local Repository folder, but what are the Archive and Update directories for?

The packages in the main repository are stored as a zip file(to minimize server load), the OPM first downloads the zip to the "Archive" directory, then unzip it to the "Local Repository" , from here the packages are installed into the IDE. The same is true for zip files downloaded from the package maintainer site, but instead of the "Archive" it's downloaded to the "Update" folder.
I choose this multiple folder solution to keep the "Local repository" clean.

[lainz]

About the update feature: The "external json" seems more easier to implement. I believe I found a solution, we can keep the central repository and update the packages from external json. I need 1-2 days to implement the feature.

Amazing. Thanks GetMem, is nice to hear that the ideas of the community are heard and implemented for the advance of this service.

[balazsszekely]

I did some initial testing...In order to get/display the latest version from the maintainer site, the OPM must connect to each server separately and read the external JSON. The average connection time(depends on the server) is 1.5-2 sec. The data read is almost instantaneous, since the file is small. However multiply 1.5-2 with 50 packages and you got the idea. Not a practical solution. Conclusions:
   1. I'm glad we did not drop the main repository, otherwise OPM speed would be painfully slow
   2. I'm forced to use a worker thread to read the external data from time to time(in the background), plus remembering the latest info somewhere for a quick display on startup

PS: To be honest I like the current solution better. The package maintainer keeps the latest version in a zip file(with a predefined name), on request the zip is downloaded/extracted and after a confirmation dialog, where the version is displayed, the package gets installed. The traffic is between the user and the external server.
This worked well until now as @minesadorada and @lainz proved with their packages. @wp came up with the same idea today.

Or even better along with the zip, the maintainer can save the actual version of the package in the first line of a text file(4.7.9.0 for example). When the users press the update button, the OPM reads then displays the version. After a confirmation dialog, the zip is downloaded or the update is canceled. What is wrong with this solution? We don't have to go through each server just to get a version info. The users are only interested in a few preferred package. I add once the package to the main repository, the maintainers update the txt file. Easy for everyone.

[lainz]

Or even better along with the zip, the maintainer can save the actual version of the package in the first line of a text file(4.7.9.0 for example). When the users press the update button, the OPM reads then displays the version. After a confirmation dialog, the zip is downloaded or the update is canceled. What is wrong with this solution? We don't have to go through each server just to get a version info. The users are only interested in a few preferred package. I add once the package to the main repository, the maintainers update the txt file. Easy for everyone.

Seems the best, so we must (at least in my case) only update a text file. The url to the text file will be in the generated json?

[balazsszekely]

Seems the best, so we must (at least in my case) only update a text file.

Exactly. This will be true for everyone, not just you.

The url to the text file will be in the generated json?

Yes it's already generated for the zip. The txt should be the same name, in your case "master".
https://github.com/bgrabitmap/bgrabitmap/archive/master.zip
https://github.com/bgrabitmap/bgrabitmap/archive/master.txt

Or perhaps I only need the a link to the text file, with two lines: line1 ---> version; line2---> link to zip. This way the zip and the txt can be in two different directories or servers for that matter.

[lainz]

Ok when you have it working tell us to upload it. Maybe you can add that to the wiki too.

[minesadorada]

@GetMem: to help you test..
I have CryptINI V0.0.9 update on my external server (.zip + json)
How can OPM show that it is available?  Currently it shows 0.0.8 as 'Available'