Online Package Manager

[JuhaManninen]

Memory leaks were weird.  I had to manually free 2 form members (a TiniFile and TStringList) in the QueryClose method to fix them.

It is not weird as Pascal has no garbage collection.
FormDestroy may be more logical place to free them. It makes kind of a pair with FormCreate.

[lainz]

@minesadorada

If you commented the AutoAdjustLayout I will see the application badly or not scaled. There is a Scaled property in 1.7 you can use to do the High DPI stuff, but is under construction AFAIK.

[balazsszekely]

You don't have to comment out that line, only change a few names...I attached the whole project fixed.

[balazsszekely]

Ok. The update will look like this(scrennshot1). When expanded(screenshot2).
Do we need color/background color? I have tried a lot of combination, it looks best with a bold/black text.
Popup balloons, memo with more detailed text?

[minesadorada]

You don't have to comment out that line, only change a few names...I attached the whole project fixed.

Thanks for that @GetMem
Committed to ccr svn as V0.1.14.0

json packager code updaters: Please update the umain Version History and project versioninfo to save me time doing diffs and merges..  The project is under svn version control.

@Getmem - opm: Good work! When trunk is updated I'll have a look.
I wouldn't worry about details of appearance until the update mechanism is tested for functionality.  How does the 'force update' look?  Perhaps when true, then 'New' could be different text?

[minesadorada]

Memory leaks were weird.  I had to manually free 2 form members (a TiniFile and TStringList) in the QueryClose method to fix them.

It is not weird as Pascal has no garbage collection.
FormDestroy may be more logical place to free them. It makes kind of a pair with FormCreate.

Hold on.
So you're saying that some member objects of TForm instantiated in TForm.Create have to explicitly freed in TForm.Destroy?
I always assumed that objects in a TForm derivative class were freed when the TForm derivative class was destroyed - automatically (garbage collection within a class)  Mind you, the Tstrings.Create method doesn't specify a parent; nor TIniFile.Create whcih I thought was curious.
Thanks for that info - I'll have to revisit some old code...

Committed to ccr svn as V0.1.15.0
- Objects freed in Form.Destroy as per JuhaMannien's advice

[balazsszekely]

@lainz
A question, the zip must be generated with the OPM or it can be any zip (like master.zip from github)?

No. You just simply zip your source. It can be the master.zip generated by github or your next stable version zipped. It's up you.

The zip must contain inside the normal .json or not?

No again. You generate the json with the tool created by you and minesadorada and send me the link.  That's it. In fact to make it easier OPM will generate the initial JSON(it's not yet imlemented), this can be later edited by your tool.

The zip/json generated by the OPM was for me, to make my work easier. It's not needed at all. If somebody wants to add a new package to the repository, just send me the link to the zip file.

I will add all the info to wiki soon.

[lainz]

Thanks. Well I think once you made the first external json you don't need the tool if you don't change the url or the zip names / package names. Just changing the version information and nothing more.

[minesadorada]

Thanks. Well I think once you made the first external json you don't need the tool if you don't change the url or the zip names / package names. Just changing the version information and nothing more.

I can't understand the lack of automation here.
If GetMem is unavailable, currently the update system fails.  Am I right there?

Why can't OPM regularly poll the http://<update_url>/<update_componentname>.json list automatically and look for version updates?  This could even be in a background thread when OPM loads (as an user-chosen option)  All that's needed is a standardised json filename for updates, and json packager provides that as a default.

[lainz]

If I understand it well, the external json replaces the external zip that was working before. Now it's better because you actually know the new version you will try to download and install.

GetMem already said that is not only the external json because downloading all the json takes more time than downloading the main json from the OPM server.

About updating the main server, that's not resolved yet, so we must wait until they decide how it will be managed. Currently you're right, GetMem is the only updating the packages. But when the package already contains an extenal json you can update it by yourself how many times you want.

[minesadorada]

If I understand it well, the external json replaces the external zip that was working before. Now it's better because you actually know the new version you will try to download and install.

GetMem already said that is not only the external json because downloading all the json takes more time than downloading the main json from the OPM server.

About updating the main server, that's not resolved yet, so we must wait until they decide how it will be managed. Currently you're right, GetMem is the only updating the packages. But when the package already contains an extenal json you can update it by yourself how many times you want.

That makes no sense.  The external json is trivial in size and quick to download and check. 41 (currently) update json files are no great burden. They point to the location of the external update zipfile, which could be of considerable size and only downloaded on user request.  Currently AFAIK the 'master' json is downloaded each time OPM shows,

[lainz]

Well he tested it and says that takes time (I've readed it somewhere here in this thread If I remember it well), so there is a kind of problem here, real one, or the library for downloading is not as fast, or something else is happening

[minesadorada]

Well he tested it and says that takes time (I've readed it somewhere here in this thread If I remember it well), so there is a kind of problem here, real one, or the library for downloading is not as fast, or something else is happening

Let me see if I understand it correctly:
1. As a server cron job, the update jsons are polled (i.e. weekly) and merged into the master json file on the server when a new version is detected.  This is invisible to users and requires no interaction by GetMem.
2. The master json file is downloaded when OPM starts on the user's system - which is current behaviour.  This is the speed bottleneck, if there is any.  It could be eased by downloading a small Hash file and checking against the local version.

I'm not seeing any issues with updating and speed.

All the component maintainer has to do is update their previously-specified UpdateZipfile and modify the corresponding update_<componentname>.json file  (that's what the json editor does).  No notifications nor human interaction are necessary.

[lainz]

Ok well we must see if they like that idea. I personally think is better, only we need a mantainer for the first commit, then the responsability is of the mantainers. On the other hand, if I don't mantain the package anymore and the download get's broken, the repository will not have that component anymore.

So is not only merging the main json, but the zip files. This was talked some days or weeks ago in this thread, and there is no consent about how to manage this.

I like your idea, but I'm not the one that will do it real or takes the decision of making it real. And positions against the automated stuff are always on.

[minesadorada]

I like your idea, but I'm not the one that will do it real or takes the decision of making it real. And positions against the automated stuff are always on.

I totally agree.  "The man who pays the piper calls the tune"

Let's see which sustainable system for package maintainers @GetMem settles on.

No harm in proposing ideas - @GetMem is a reasonable person; open to ideas AFAIK.

On the other hand, if I don't mantain the package anymore and the download get's broken, the repository will not have that component anymore.

With the system as proposed: the auto-checking would automatically remove the component from the master tree if the URL went bad.  That's correct behavior for unmaintainable/obselete components, surely?  That's why many components from the ccr were not included in the initial master list AFAIK.

So is not only merging the main json, but the zip files. This was talked some days or weeks ago in this thread, and there is no consent about how to manage this.

Why merge the zip files on the OPM server by default? The initial (vetted) zips can be canonical. The user chooses to update their local repository or not (with a suitable warning).  The 'Available' column reflects the 'available update version'.  That makes sense for a user. I thought that was the point of the 'force update' option in the update json - where the canonical version is somehow faulty or out-of date and has to be replaced on the server - not default behaviour.

I'm trying to look 3 - 5 years ahead with Laz 2.x/OPM when active maintenance of OPM may not be so available as now.

I'm very enthusiastic about @GetMem's initiative - it was an needed idea for Lazarus waiting to happen, and makes Lazaus look more professional to new and old users alike.