Online Package Manager

[GetMem]

@wp
Thanks for the new package. I added to OPM.

[wp]

GetMem, could you update two packages in OPM:

• CalLite: no more flicker (see https://forum.lazarus.freepascal.org/index.php/topic,45526.0.html). Package download at https://sourceforge.net/projects/lazarus-ccr/files/CalLite/callite-0.3.6.zip/download; JSON update link location as before, but included in the attached zip.
• JVCLLaz: a lot of new components, see http://wiki.freepascal.org/JVCL_Components. Download link is https://sourceforge.net/projects/lazarus-ccr/files/jvcllaz/jvcllaz-1.0.5.zip/download. Due to the large number of added sub-packages I created a new download json file - see attachment. I tested the components on
  * Win10/64 bit with
    - Laz trunk/FPC trunk (32 bit)
    - Laz trunk/FC 3.0.4 (32 bit)
    - Laz 2.0.2/FPC 3.0.4 (64 bit)
    - Laz 2.0.0/FPC 3.2 (32 bit)
    - Laz 1.8.4 / FPC 3.04 (32 bit)
  * Linux Mint 18.1xfce /32 bit
    - Laz trunk / FPC 3.0.4 (32 bit): gtk2 and qt
  * Ubuntu 18.04/ 64 bit
    - Laz trunk / FPC 3.0.4 gtk2
  I updated the package descriptions to reflect these versions. I am rather sure that the packages will work on other OSs/widgedsets as well, and I am also sure that some (but not all) of the (many) packages work also on Laz/FPC older than v1.8.4/3.04 respectively. But my testing capabilities are limited, <begin lamenting> and just to test each one of the 32 packages and 43 sample demos is an enormous effort... </end lamenting>.
  

But seriously again: It was discussed in another thread that OPM should check this information when a package is installed. AFAICS now, mismatching versions should only yield a warning but not prohibit installation.

Widgetsets should be made selectable from a combobox instead of allowing free text entry; also, I a missing some way to specify whether a package is suitable for 32bit/64bit targets.

[GetMem]

@wp

GetMem, could you update two packages in OPM:

I updated the packages. Thanks for the new versions.

But seriously again: It was discussed in another thread that OPM should check this information when a package is installed. AFAICS now, mismatching versions should only yield a warning but not prohibit installation.

I did try to implement it(at least in theory), but I failed. It looks simple, but believe me is not simple at all. I can add a selectable combobox, but who's gonna list all the widgetsets other then the obvious ones(win32/64, gtk2, qt, carbon, cocoa). How can I found the actual widgetset? I need a ton of ifdefs? Like this?:

Code: Pascal  [Select]

1.  {$ifdef win64}
2.   CurWidgetset = win64;
3.   {$endif}
4.   {$ifdef win32}
5.   CurWidgetset = win32;
6.   {$endif}
7.   //...

Where can I found the list with all possible WS and the ifdef equivalent?
What should I do with the following, already existing widgetset description(this was taken from the main json, it's a real case): "Not a design-time package"?
What about Lazarus/ FPC versions? Should I differentiate between versions and subversion, like 2.0.0/ 2.0.2?
How can I preserve the compatibility between the new json(with all the selectable widgetsets, Lazarus/FPC versions) and the old one? 

[wp]

Looking back this thread I see that I did not remember the discussion correctly (I was referring to the discussion around this topic: https://forum.lazarus.freepascal.org/index.php/topic,34297.msg319438.html#msg319438).

In my incorrect memories I had thought that the installation of a package by OPM should only be done when there is a precise match of widgetset and Lazarus/FPC version. Besides the issues that you mention I also believe that this requirement puts an immense burdon on the package maintainers, and I fear soon installations will be blocked by unmaintained package descriptions.

Restricting to FPC alone as discussed above is only half the story and not satisfying to users because it will not be understood that the FPC version is checked by the installer but the widgetset not.

Therefore, I think that OPM should remain as it is.

[korba812]

How can I found the actual widgetset?
...
Where can I found the list with all possible WS and the ifdef equivalent?

You will get this information in "LCLPlatformDef" unit.

If you need ifdef it is defined as "LCLplatform" eg LCLwin32 or LCLgtk2 etc.
{$ifdef LCLwin32}....{$endif}

[avra]

In my incorrect memories I had thought that the installation of a package by OPM should only be done when there is a precise match of widgetset and Lazarus/FPC version. Besides the issues that you mention I also believe that this requirement puts an immense burdon on the package maintainers, and I fear soon installations will be blocked by unmaintained package descriptions.

There should be no restrictions during installation attempts. It would be ideal if OPM could simply determine widgetset/architecture/laz/fpc combo, contact server to get installation failure rate (something like 522/741 meaning success/attempts), get last successful/unsuccessful package installation date for such combo (get all this info while reading list of available OPM packages), and show it to the user next to each package. Package success and combo info (if allowed by user) should be sent to server. At the beginning (and with each new fpc/laz version) this info will not show much, but in time data will be more and more accurate. If available, full version info should be matched (like 2.0.3 or 3.0.4) and shown, but if not then more relaxed partial version info should be looked for (like 2.0 or 3.0) and shown with warning color. Shown info would not be a guarantee that a package will be installed (trunk?), but it will be a good statistical probability info before any package installation attempt. Last successful and installation date of the package for user's combo would be especially informative to the user.

[GetMem]

Sorry for the late response and thanks for the suggestions.

@wp
I remember the discussion. I think I found a reasonable solution for everyone.

@korba812
LCLPlatformDef is a life saver. Thanks.

@avra
For now, the communication between the server and OPM is in a single direction. The site admin only allows upload if a CGI is implemented(security reasons). This is why I did not completed the voting system. For the same reasons, any other statistics is also out of reach.

I implemented the "incompatible package" warning. A few notes:
1. The warning is optional(see image1). If the checkbox is unchecked, everything works as it did until now. For testing purposes the option is enabled by default, it can be disabled later if needed. Even when enabled, the user has the possibility to continue the install process.
2. I only added stable Lazarus/FPC versions + trunk for both(see image2). By default the following versions are supported:
     Lazarus:  2.0.0, 2.0.2
     FPC: 3.0.0, 3.0.2, 3.0.4
     WidgetSet:  win32/win64, gtk2
In my experience almost every package supports the above Lazus/FPC versions and widgetsets. When needed, a package maintainer can extend the list. If a new stable version appears, I will extend the default list. Old, obsolete versions like Laz. 1.6.0 are no longer supported.
3. The warning dialog looks like this(see image3), more detailed information can be obtained from hint.
4. The feature does not require any extra work from the package developers.
5. The feature is compatible with older versions of OPM.
5. I did not have time to test extensively. I will fix the reamining bugs later.

PS1: Suggestions as always are welcomed.
PS2: If you wish to test, try to install LazProfiler. The package needs Laz/FPC trunk, any other configuration should trigger the warning message.

[Onur2x]

Online Package Manager for turkish language packed pls add . thnx you

[GetMem]

@Onur2x

Online Package Manager for turkish language packed pls add . thnx you

Thanks. I sent the files to @Maxim.

[Lainz]

Sorry for the late response and thanks for the suggestions.

@wp
I remember the discussion. I think I found a reasonable solution for everyone.

@korba812
LCLPlatformDef is a life saver. Thanks.

@avra
For now, the communication between the server and OPM is in a single direction. The site admin only allows upload if a CGI is implemented(security reasons). This is why I did not completed the voting system. For the same reasons, any other statistics is also out of reach.

I implemented the "incompatible package" warning. A few notes:
1. The warning is optional(see image1). If the checkbox is unchecked, everything works as it did until now. For testing purposes the option is enabled by default, it can be disabled later if needed. Even when enabled, the user has the possibility to continue the install process.
2. I only added stable Lazarus/FPC versions + trunk for both(see image2). By default the following versions are supported:
     Lazarus:  2.0.0, 2.0.2
     FPC: 3.0.0, 3.0.2, 3.0.4
     WidgetSet:  win32/win64, gtk2
In my experience almost every package supports the above Lazus/FPC versions and widgetsets. When needed, a package maintainer can extend the list. If a new stable version appears, I will extend the default list. Old, obsolete versions like Laz. 1.6.0 are no longer supported.
3. The warning dialog looks like this(see image3), more detailed information can be obtained from hint.
4. The feature does not require any extra work from the package developers.
5. The feature is compatible with older versions of OPM.
5. I did not have time to test extensively. I will fix the reamining bugs later.

PS1: Suggestions as always are welcomed.
PS2: If you wish to test, try to install LazProfiler. The package needs Laz/FPC trunk, any other configuration should trigger the warning message.

About the CGI: we're talking about Linux right? The CGI which database should use?

There's a package I was testing the other day that provides simple server, CGI, Apache and other modes with modules as endpoints or as well the newest version using routes. Fcl-web or package weblaz.

At work I use sqlite and an executable that works as a local server with a lot of get and post endpoints that are threaded. It should be something like that. We use a browser to run the HTML and js app in localhost and consume the endpoints. In this case will be a internet server instead of a local one. And the endpoints should be consumed from opm only... That's the hard part since there's no login to vote. One can send an unlimited number of votes from postman for example... Else we need to make a login system as well.

[avra]

Something needs to be changed for pl packages in OPM. Installing 5-6 packages at a time I installed all pl packages except pl_dwscript which could not compile now on 2.0.3, although it worked on 2.0.1. I will deal with that later. The problem I report is that later I tried to install pl_dwscript package with some other packages, and after OPM failed to install it again, I left OPM and returned to IDE. IDE reported that files of all pl packages changed and need to be reloaded but failed to do so. When I looked in ct4laz dir, there was only pl_dwscript package. All other pl packages were missing. I had to reinstall them all again. Funny thing is that I am pretty sure that once or twice I tried to install only problematic package and OPM did not delete other packages, but now that I tried to install it with other packages, when failed OPM deleted all other already installed pl packages. If you want you can disable pl_dwscript in OPM and we can leave it only in ct4laz.

Fresh Lazarus 2.0 fixes and FPC 3.2 fixes 32bit via fpcupdeluxe on Win10x64.

EDIT: It is not just the case with pl packages. The same just happened with PlotPanel package:

Error reading file: Unable to open file "C:\PRG\Lazarus\Fixes20x32x\config_lazarus\onlinepackagemanager\packages\plotpanel-lazarus-0.97.1\plot.lpk"

[GetMem]

Hi all,

I'm on vacation for two weeks. I will address the issues when I return. Sorry for the inconveniences.

[Lainz]

Have a good vacation