Online Package Manager

[piGrimm]

@Getmem you're welcome! thanks to you
yep, alone getmem can become overflawn/overflood (just kidding) 

[lainz]

Hi @GetMem, sorry If I bother you again.

I've updated BGRAControls to fix the compilation problems in tunk, in Linux due to changes to ImageList. The best is to become BGRAImageList equal to ImageList for now until it get's ready and I can see how to make a new one.

I don't know if I can upload the new release or if actually is as always you the only with privileges to do it. Because in this case, an update will not work since it's required to be installed first, and that is just the thing i'm fixing.

Thanks.

[wp]

I think I will add SVN support soon. It will be the user choice to install the trunk version or not. The package.json already has a SVN entry, which is not used yet.

Does this mean that OPM will create the zip file by itself from the svn files? How does it know that the svn sources have been changed? Does the package maintainer have to update the update.json every time he commits changes to svn? This would not be good because this will not happen, and the users will get an outdated svn version. Or will OPM regularly scan all the available svn repositories for the current revision number and compare with an internal list?

[balazsszekely]

Does this mean that OPM will create the zip file by itself from the svn files? How does it know that the svn sources have been changed? Does the package maintainer have to update the update.json every time he commits changes to svn?

When the user decide to switch to the trunk version of a particular package, OPM will act like as a SVN/GIT client and will do a checkout/update or clone/pull respectively.  The package maintainers don't have to do anything other then provide a link(once) to package trunk. The user will have the possibility to switch back to a stable version if needed by using the "Install"/"Update" buttons. At least this is the idea, I did not implemented anything so far.

[marcov]

I have some code to get logmessages for revisions using  "svn log -v", given a range of revisions.

This include mutated files, which one could then transform into mutated toplevel directories (=packages)?

(I'm thinking about e.g. a lazarus-ccr structure here, if opm is different, nevermind)

[sam707]

just an idea...
would it be difficult to turn OPM (OnlinePackageManager) into a kind of multisource thingey (likewise simplistic dedicated bitorrent)?

I think there would be many advantages
- no storage server (or centralized cloud) needed = autonomy
- keys to check validity of zip archives only on short master tracker
- list of authored people (packages mainteners) on master tracker, other are anonymous clients with no modify rights
- each anonymous client "can" configure its OPM to conribute with a minimal bandwidth to lend

disavantage
- less appreciated packages are going to get more time at download, but the stars notation system is also going to be automatic after few statistic months

[balazsszekely]

@marcov
Thanks for the suggestion. The OPM structure is different, now it relies on zip files, the packages are zipped(main repository) to minimize traffic load on download. Since a lot of users prefer the trunk version of a particular package, I was thinking to add the possibility to download the whole trunk directory as any svn/git client would do, from the maintainers webpage.

@sam707

just an idea...
would it be difficult to turn OPM (OnlinePackageManager) into a kind of multisource thingey (likewise simplistic dedicated bitorrent)?

The idea is good, but I'm afraid OPM wasn't designed for that kind of functionality. I would have to rewrite a large part of OPM to support a bittorrent like feature. Unfortunately I don't have the time or the energy to do that.

[lainz]

+1 to SVN idea, really good to install from repository without having to find them.

[Josh]

@getmem
Just an idea, that would make it far more useful to me , would be if I set the download folder to be my central component folder, then when components are downloaded they are stored in a folder that also contains there version number, ie BGRABITMAP_8_5_2 etc, that way when I update a component in one of my lazarus installation, it will not effect the other installations; until I am ready to upgrade those as well.  As I have some old lazarus installations that are still in use but not all the updated component/libraries work with.

[balazsszekely]

@josh

Just an idea, that would make it far more useful to me , would be if I set the download folder to be my central component folder, then when components are downloaded they are stored in a folder that also contains there version number, ie BGRABITMAP_8_5_2 etc, that way when I update a component in one of my lazarus installation, it will not effect the other installations; until I am ready to upgrade those as well.  As I have some old lazarus installations that are still in use but not all the updated component/libraries work with.

The problem is each package can contain multiple lpk files with different versions. Which one to choose as folder name(see attached image)?

[dsiders]

I finally got around to installing and using OPM. Seems like a very nice start. Now for the obligatory stupid question.

I see that OPM has a new version, but I cannot update from inside OPM. I'm assuming that's because it does not have an "Update JSON" link. So the question is... how does one update OPM if it cannot be done using OPM?

[balazsszekely]

@dsiders

I finally got around to installing and using OPM. Seems like a very nice start.

Thank you.

Now for the obligatory stupid question.

There are no stupid questions.

I see that OPM has a new version, but I cannot update from inside OPM. I'm assuming that's because it does not have an "Update JSON" link. So the question is... how does one update OPM if it cannot be done using OPM?

If you're using Lazarus 1.8, you can update to OPM 1.0.1.2 by pressing the "Install" button. The difference between Install and Update is described here: http://wiki.freepascal.org/Online_Package_Manager#Difference_between_download.2Finstall.2Fupdate
There is an even newer version of OPM in Lazarus trunk but you can not install it into a stable version because breaks code(this is the reason you don't see an update json for OPM). Lately there was a lot of changes to make OPM more compatible with the internal package system(see attached images). So basically you have two choices:
1. Stay with Lazarus 1.8/OPM 1.0.1.2
2. Use Lazarus trunk

[Josh]

@getmem
The whole component/module has a version number, ie bgrabitmap 9.6.1.

If the new version has issues and creates problems, it is easy to revert back to a previous version, at the moment I do this manually using install pkg, but if opm created such a file structure, then OPM could have this archive feature added in, with an option to enable it or disable it.
Another use for the archive idea, is if a new version introduces a bug, you can then go back and find which version introduced the bug, to aid in tracking it down.

possible folder structure
bgrabitmap/V8.5.2/.......
bgrabitmap/V9.6.0/........
bgrabitmap/V9.6.1/........

Thats the idea, whether you or others would find such a feature usefull I do not know. I have not checked out the source for OPM to see how easy such a feature would be to add in.

[balazsszekely]

@Josh
Your request seems logical and reasonable, however it will introduce new issues that would be extremely difficult to solve. As you probably know OPM automatically resolve dependencies(as far as depth 10). For example if you wish to install component Rx, which depends on Zeos and FpSpreadsheet, OPM will automatically install both packages before Rx to prevent missing dependencies error. Now if we add more then one version of a particular package, OPM would have a hard time to decide which version should install(when resolving dependencies), because the .lpk name stays the same in each version. This is the reason why each meta and lazarus package inside the main repository must be unique. For example take a look at VirtualTreeView, you will find two version 4.8.7 and 5.3.3 however the lpk from the former one is renamed to virtualtreeview_package4 to prevent confusion.
Even the internal packager can not handle more then one version of a package, I mean you cannot install different versions of same package at the same time.

[lainz]

Is a good explanation. This is not intended to be like NPM (Node Package Manager).
The problem is not OPM, but how Lazarus packages works from the start.

If SVN/Git is added, please add the option to stick to some revision, so you're sure wich version you're using at a repository level. Just search the version commit, or even better list each version in the package to choose one, and problem solved.