Online Package Manager

[balazsszekely]

@wp

Thanks for testing the package manager.

Now that Luiz has disabled the ccr version of VirtualTreeView which I did not want to bypass by adding comment braces around the very efficient installation stopper lines I decided to go the future way and get myself the "official" VirtualTreeView 4.8 using the OPM. I uninstalled the old VTV version (which was in a folder shared between a variety of Lazarus installations), then installed the current OPM from Lazarus trunk, checked virtualtreeview-4.8.7-R4 in the OPM and clicked Install. Fine. But the recompilation of the IDE stopped because of "The unit registervirtualtreeview exists twice in the unit path of the IDE." - the message lists the paths of the old and new installations. Using "Package" / "Package Links" I removed the old path from the list of known packages - still the same error.

Unfortunately I don't have an answer to your question. I repeatedly reinstalled VST over an existing installation, without errors. The compile/install/rebuild process is done by the IDE through the "PackageIntf" interface, OPM only "asks" the IDE to compile the packages and rebuild itself when needed, if the IDE says there is a duplicate path, probably is somewhere. This is the kind of error message I was afraid of when I decided to add VST internally to the package manager.

What to do? Where do I have access to the "unit path of the IDE" so that I could delete the old directory?

Deleting or renaming the old VST directory should solve the problem.

Another point - maybe this already has been suggested, excuse me in this case: When clicking "Install" in the OPM there is no way to control the destination folder. With the VTV issue I know that the installation goes into the profile folder. This is fine in most cases, but I could imagine there are users (like myself) who want to put all third-party components into a common folder which is shared between several Lazarus installations. So, I would appreciate if there were a selection box for the destination directory in the OPM Options dialog.

Consider it done. I will try to implement it today.

[minesadorada]

A Suggestion:
In the Create Package dialog, a button 'Submit Package?' - meaning 'Submit Package for consideration for the public Online Repository' (wouldn't fit on a button!)

This would perhaps trigger a stock dialog, where the submitter is asked various questions (incl. contact info), and the info then gets zapped to the OPM maintainer (currently GetMem)

[wp]

As for the VirtualTreeView installation, it is working now. The problem was that I still had installed other components which depend on VTV. After uninstalling them the IDE compiles again, and I finally could install the OPM version of VTV.

[balazsszekely]

@minesadorada
In the Create Package dialog, a button 'Submit Package?' - meaning 'Submit Package for consideration for the public Online Repository' (wouldn't fit on a button!)
This would perhaps trigger a stock dialog, where the submitter is asked various questions (incl. contact info), and the info then gets zapped to the OPM maintainer (currently GetMem)

It's already in the to do list for a long time, but there is a problem. Where to submit the packages/JSON/contact Info?
1. To http://packages.lazarus-ide.org/
   We need a folder with public access, the risk of spam is high
2. Send by mail to me or somebody else
   In order to send a mail directly from OPM, the user must install the OpenSSL library.
3. Upload to a FTP server
  This is my favorite solution. But upload where? We need a public FTP somewhere.

I'm open to suggestions.

@wp
As for the VirtualTreeView installation, it is working now. The problem was that I still had installed other components which depend on VTV. After uninstalling them the IDE compiles again, and I finally could install the OPM version of VTV.

Ok. I'm glad it's working.

[JuhaManninen]

3. Upload to a FTP server
  This is my favorite solution. But upload where? We need a public FTP somewhere.

You could ask Marc and Vincent if they can start an FTP server in the same machine where http://packages.lazarus-ide.org/ is.
The disk space could be limited to prevent huge files uploaded either by accident or intentionally.

[wp]

@GetMem: I just uploaded a new zipped release version of CalLite (version 0.3). In addition, I also added a file callite-current-release.zip which is identical to the 0.3 version file. In future releases the most recent file will always be duplicated under this name. Therefore, if you link the OPM to callite-current-release.zip (https://sourceforge.net/projects/lazarus-ccr/files/CalLite/callite-current-release.zip/download), it will always catch the most recent file (except for the short interruption it takes me to replace the old file by the new one - btw: how does OPM behave if a zip file is not available?).

I am planning to keep this naming scheme with all the repositories that I am maintaining.

[JuhaManninen]

@GetMem: I just uploaded a new zipped release version of CalLite (version 0.3). In addition, I also added a file callite-current-release.zip which is identical to the 0.3 version file. In future releases the most recent file will always be duplicated under this name. Therefore, if you link the OPM to callite-current-release.zip (https://sourceforge.net/projects/lazarus-ccr/files/CalLite/callite-current-release.zip/download), it will always catch the most recent file

Sorry but it does not solve anything. Information about the new version is not passed to the package manager.
When you update to version 0.4, keeping the same callite-current-release.zip file name, the package manager's JSON file still shows version 0.3. It would have to download and extract the zip file to get its real version, but that is too much traffic.

Earlier I (and others, too) suggested an external JSON file for the version etc. info.
It should be supported to move admin work from GetMem to maintainers of individual packages.

[wp]

Thanks. I guess I should read all 276 posts...

So, I'll remove the callite-current-release.zip again, and wait for instructions how to setup the JSON file. The zip file for OPM is callite-0.3.zip then (https://sourceforge.net/projects/lazarus-ccr/files/CalLite/callite-0.3.zip/download).

[minesadorada]

@GetMem: I just uploaded a new zipped release version of CalLite (version 0.3). In addition, I also added a file callite-current-release.zip which is identical to the 0.3 version file. In future releases the most recent file will always be duplicated under this name. Therefore, if you link the OPM to callite-current-release.zip (https://sourceforge.net/projects/lazarus-ccr/files/CalLite/callite-current-release.zip/download), it will always catch the most recent file

Sorry but it does not solve anything. Information about the new version is not passed to the package manager.
When you update to version 0.4, keeping the same callite-current-release.zip file name, the package manager's JSON file still shows version 0.3. It would have to download and extract the zip file to get its real version, but that is too much traffic.

Earlier I (and others, too) suggested an external JSON file for the version etc. info.
It should be supported to move admin work from GetMem to maintainers of individual packages.

When I made the external cryptini.zip 'update file' I put 'cryptini.json' in the same server location. (it's also in the zip of course)
I assumed that was the way to do maintenance updates.  I'm obviously ahead of myself!

Hey - wouldn't it be nice if the json file could have a 'What's new in this version' entry?
 

[lainz]

Hi, I'm also waiting for GetMem response to upload the Json file.

Where I must download the package manager from now, it is still beign updated on github or I must switch for the lazarus components one? I want to create the json with the latest of course.

If I remember well I also don't response a question of GetMem, where I can upload the json file on GitHub, well this can be done in two places:
- Along with the sources, then you can get it thanks to the raw.githubusercontent website with no need of git, so is served like a text file.
- In a release, but this must be a special release that I must update every time I change the json. So delete the previous and upload it again.

I think I will use the first.

I don't know how you GetMem will test it, if you need a new release of some of the packages I mantain I can do one, since I have some changes in the repositories that can apply for a new release, at least for a minor one.

[balazsszekely]

@wp
So, I would appreciate if there were a selection box for the destination directory in the OPM Options dialog.

Implemented in r.53424

@Juha

You could ask Marc and Vincent if they can start an FTP server in the same machine where http://packages.lazarus-ide.org/ is.
The disk space could be limited to prevent huge files uploaded either by accident or intentionally.

Ok. I will send a mail to Marc.

@Juha

Earlier I (and others, too) suggested an external JSON file for the version etc. info.
It should be supported to move admin work from GetMem to maintainers of individual packages.

Yes, but the external json idea is not fully implemented + I always thought that the packages from the main repository will be manually added/updated for security reasons. The main repository will contain the most 25 popular packages(or whatever number you find appropriate). If not the whole central repository is pointless. Without a central repository all we need is a master json(make it a txt), that contains the links to the developer's JSON.

Again I'm open for suggestions.

@minesadorada
When I made the external cryptini.zip 'update file' I put 'cryptini.json' in the same server location. (it's also in the zip of course)

That JSON is concatenated to the main one from the central repository. It was designed for me, it's not the "external json" that @Juha and @lainz talks about.

[lainz]

Yes, but the external json idea is not fully implemented...

Ok that's the response I was looking. So from now uploading it is not neccessary.

[JuhaManninen]

Where I must download the package manager from now, it is still beign updated on github or I must switch for the lazarus components one? I want to create the json with the latest of course.

The master is in Lazarus sources now. It is best the download from there (together with the whole Lazarus trunk maybe).
I have updated the wiki page, too.

[lainz]

Where I must download the package manager from now, it is still beign updated on github or I must switch for the lazarus components one? I want to create the json with the latest of course.

The master is in Lazarus sources now. It is best the download from there (together with the whole Lazarus trunk maybe).
I have updated the wiki page, too.

I've downloaded it with Fpcupdeluxe with also trunk of fpc, but bgrabitmap doesn't compile, seems that they're working in changes of assembler and that code is not working in the package.

So I need to download FPC 3.0 + lazarus trunk. It will work? I need bgrabitmap for my projects and packages so is the only thing I can do.

[balazsszekely]

@lainz
I've downloaded it with Fpcupdeluxe with also trunk of fpc, but bgrabitmap doesn't compile, seems that they're working in changes of assembler and that code is not working in the package.So I need to download FPC 3.0 + lazarus trunk. It will work? I need bgrabitmap for my projects and packages so is the only thing I can do.

While testing the package manager, I installed bgrabitmap/bgracontrols/bgracontrolsfx several times today. It works fine. I also have FPC 3.0.0 + Lazarus trunk. So the answer is yes.