Online Package Manager

[Josh]

@getmem
If its not easily doable, no problem I will keep using my existing system.
It was just an idea, that may help people that have multiple version installations using the same local repository to avoid an update of one lazarus installation effecting the other installation.

[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.

I quote myself so this message don't get lost, I think if that feature is developed will help you the actual way you manage packages.

[dsiders]

Now for the obligatory stupid question.

There are no stupid questions.

Give me some time.... you may change your mind. <g>

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

Thank you. Will try it out shortly.

[JuhaManninen]

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/........

Bad idea! You essentially try to turn OPM into a revision control system and bisect bugs with it.
No, OPM is a delivery system for tested released packages. For bug haunting you must use the actual revision control system like you did before OPM existed.

Extending OPM to get latest sources directly from revision control may be a swamp. The benefit is that a user does not need to search for the repository's URL explicitly, good. But what if the latest revision has a bug? Where does he report it? Will OPM also have a link for the project's bug tracker and warnings that OPM is not its main development tool?
There is a danger that people get a wrong idea and report bugs in Lazarus bug tracker instead of the correct project.

[balazsszekely]

@Juha

Extending OPM to get latest sources directly from revision control may be a swamp.

Although I have working code for SVN, I'm still reluctant to commit. I'm also under the impression that will cause more trouble then good. 

[minesadorada]

I'm with Juha on this.
OPM has a good system for delivering latest_stable components, and SVN revisions/branches etc. would be unneeded bloat IMO.

[lainz]

Hi, there is BGRABitmap 9.6.1, @circular did not add the update.json, yet. BTW is optional and there is no problem on don't having it, is the normal and original OPM way to use it.

If the SVN thing is a bad idea for @GetMem then don't add it, is your system and you decide what is good or not.

This don't need to be like NPM where you can grab any version, and use any version on each single project. Things work different here, I think. First that packages are per Lazarus installation usually. If you need per project there already are the Project Options.

I think having packages installed by OPM in a global folder is not a good idea. And then if you need an exact revision, better shipt it with your project until it get's lost.

Yes, I get convinced 

[balazsszekely]

Hi, there is BGRABitmap 9.6.1, @circular did not add the update.json, yet. BTW is optional and there is no problem on don't having it, is the normal and original OPM way to use it.

Done.

If the SVN thing is a bad idea for @GetMem then don't add it, is your system and you decide what is good or not.

The idea is good but most likely will introduce new issues which is bad. 

[wp]

GetMem, I updated spktoolbar today to v0.1.6 (improved LCL-Scaling, support of new Hi-DPI image list, avoid flicker after recent changes in LCL), but OPM tells me that there's still v0.1.5 in the repository. I probably did something wrong - again...

[balazsszekely]

Hi wp,

It works fine for me, nevertheless I also updated the package in the central repository, so the default version now is v0.1.6 .

[wp]

I think I asked this already, and you probably explained it a thousand times...

There seem to be always two download locations:
- the one which I specify in the updatejson - this is the version in column "Update" - and which is updated by the local client in an interval specified in the "Options",
- the central repository which is updated from time to time by yourself or maybe by some process running on the server.
Is this correct?

Without understanding this, the columns in the OPM window ("Repository", "Update") are confusing. Does the user have to know these internals? Can't they be merged to one?

Another confusing information is in the column "Status/Data": spktoolbar in trunk has the version number 0.1.7 - this is what is installed on my system, but the column says "Up to date". I think this is wrong, it should be "Ahead of OPM" or "Development version".

[balazsszekely]

There seem to be always two download locations:
- the one which I specify in the updatejson - this is the version in column "Update" - and which is updated by the local client in an interval specified in the "Options",
- the central repository which is updated from time to time by yourself or maybe by some process running on the server.
Is this correct?

Yes.

Without understanding this, the columns in the OPM window ("Repository", "Update") are confusing.

I agree it is confusing, but I think I did explained relatively well here(or at least I tried  ): http://wiki.freepascal.org/Online_Package_Manager#Difference_between_download.2Finstall.2Fupdate

Does the user have to know these internals? Can't they be merged to one?

This is a good question. Initially the separation(install/update) was introduced for two reasons:
1. To offload the bulk of the work from the central repository to the package maintainer(s), this way making the whole system sustainable on the long run.
2. To prevent infection, which is especially important under windows. The user must know that now it will install something from the maintainer webpage, which in theory can contain malicious stuff
The ideal solution is to create login system for package maintainers, which would allow to modify the packages inside the main repository directly. Since the lazarus webpage was compromised in the past, Marc only agrees if somebody creates a cgi backend in pascal or php. Unfortunately I don't have the time or the energy to implement such a complex system, at least not now. 

Another confusing information is in the column "Status/Data": spktoolbar in trunk has the version number 0.1.7 - this is what is installed on my system, but the column says "Up to date". I think this is wrong, it should be "Ahead of OPM" or "Development version

By up to date I meant: you cannot get a newer version with OPM, but I can change it to "Ahead of OPM", it sounds good.

[wp]

Without understanding this, the columns in the OPM window ("Repository", "Update") are confusing.

I agree it is confusing, but I think I did explained relatively well here(or at least I tried  ): http://wiki.freepascal.org/Online_Package_Manager#Difference_between_download.2Finstall.2Fupdate

Yes, I remember now.

But having forgotten about this page, I see another misunderstanding on my side: I understood "Update" to be a command to update an existing package installation as it is commonly used, but you mean "install, or update, from package maintainer source", in contrast to "Install" which is from Repository source. What about merging these two buttons to a single "Install" which opens a dropdown menu with the entries "from repository" and "from external source". Then, maybe, the column "Update" could be renamed to "External".

Does the user have to know these internals? Can't they be merged to one?

This is a good question. Initially the separation(install/update) was introduced for two reasons:
1. To offload the bulk of the work from the central repository to the package maintainer(s), this way making the whole system sustainable on the long run.
2. To prevent infection, which is especially important under windows. The user must know that now it will install something from the maintainer webpage, which in theory can contain malicious stuff
The ideal solution is to create login system for package maintainers, which would allow to modify the packages inside the main repository directly. Since the lazarus webpage was compromised in the past, Marc only agrees if somebody creates a cgi backend in pascal or php. Unfortunately I don't have the time or the energy to implement such a complex system, at least not now. 

You never can be absolutely safe from malicious software. If there is a black sheep among us developers the login system for package maintainers won't be an improvement. How will you be sure that the package author you gave permission to modify the repository is not a bad guy? I would forget about this idea.

Another confusing information is in the column "Status/Data": spktoolbar in trunk has the version number 0.1.7 - this is what is installed on my system, but the column says "Up to date". I think this is wrong, it should be "Ahead of OPM" or "Development version

By up to date I meant: you cannot get a newer version with OPM, but I can change it to "Ahead of OPM", it sounds good.

No, the newer version is not obtained with OPM, it is a locally installed package which, by incidence, is also distributed by OPM.

[balazsszekely]

What about merging these two buttons to a single "Install" which opens a dropdown menu with the entries "from repository" and "from external source". Then, maybe, the column "Update" could be renamed to "External".

This is an excellent idea. I will implement it next week.

You never can be absolutely safe from malicious software. If there is a black sheep among us developers the login system for package maintainers won't be an improvement. How will you be sure that the package author you gave permission to modify the repository is not a bad guy? I would forget about this idea.

True. There is no system that's 100% safe, but with this method the "Update" button will completely disappear and the central repository would be maintained almost entirely by package maintainers.

[minesadorada]

There is no system that's 100% safe, but with this method the "Update" button will completely disappear and the central repository would be maintained almost entirely by package maintainers.

The problem with a wholly user-maintained system is ensuring quality control.  OPM needs a "gatekeeper" to exclude incompatible, out-of-date or uncompileable packages from entering the system.