Online Package Manager

[JuhaManninen]

So that only becomes TRUE when Lazarus is at V1.8.  How is that testable?

See, more confusion...
GetMem, please remove the GitHub mirror or add a line to its sources that prevent compilation.
OPM is now part of Lazarus sources. Period!
It should be easy enough to understand for everybody.

[minesadorada]

In which case the revised {$IFDEF} is correct, since trunk will presumably be eventually released as V1.8.

[JanRoza]

@JuhaManninen: No need to immediately call met stupid.   
I indeed had an older trunk and looking at the source of the offending opk module it looked as if lazarus 1.7 was sufficient.

Just to stop people calling me stupid    I made a second Lazarus installation with the latest trunk and in this installation everything seems to be working perfectly.

[JuhaManninen]

@JuhaManninen: No need to immediately call met stupid.   
I indeed had an older trunk and looking at the source of the offending opk module it looked as if lazarus 1.7 was sufficient.

Actually I wrote: "you are doing something stupid". Clearly you were misguided by the confusing OPM mirror situation. Even clever people can be misguided by it.

Just to stop people calling me stupid    I made a second Lazarus installation with the latest trunk and in this installation everything seems to be working perfectly.

Why a second Lazarus installation? Why not just "svn up"?

[JanRoza]

No offence taking, I was just teasing a bit.
I'm always a bit cautious, when I have a working situation I leave that intact and create a new folder with a secondary installation (and configuration).
Once I'm satisfied i delete the old installation.
Maybe not the simplest way but I never loose my working environment this way in case I really do something stupid. 
 

[Xor-el]

Just downloaded the latest trunk version of Online Package Manager but when I try to install the package in Lazarus 1.7 (FPC 3.1.1) I get the following error:

opkman_installer.pas(166,40) Error: identifier idents no member "DoCompilePackage"

Any ideas how to solve this? Is there a minimum trunk version of Lazarus I need?

When using trunk the minimum version is the latest trunk.
According to your error message you are doing something stupid now. I think you download OPM from the GitHub mirror and try to install it in an old Lazarus trunk. Am I right?
Hey, OPM is already part of Lazarus trunk!
Still synchronizing the old repository is counter-productive. It only creates confusion (as happened now).
I still think the old repo should be either removed or deprecated.
There are already at least 2 mirrors for the code in GItHub. Explicitly synchronizing a 3rd one makes no sense!
I honestly don't understand why Xor-el suggested it and why GetMem agreed.

I understand your worries, but not everybody wants to download the whole repo just to get a few files.

[JuhaManninen]

I understand your worries, but not everybody wants to download the whole repo just to get a few files.

This will get you only the OPM sources:

Code: [Select]

$ svn co http://svn.freepascal.org/svn/lazarus/trunk/components/onlinepackagemanager OPM
Actually I already wrote it earlier. Later update it with:

Code: [Select]

$ svn up
just like with any repository.

[balazsszekely]

1. Ok. No more github
2. I extended the category list. You can assign multiple categories to a package(attachment 1)
3. Description and license can be viewed in a separate form(attachment 2)

[wp]

Today I uploaded a new release (=zip) version of tvplanit: https://sourceforge.net/projects/lazarus-ccr/files/tvplanit/tvplanit-1.06.zip/download.

[balazsszekely]

@wp
I updated callite and tvplanit.

[minesadorada]

Updated CryptINI to V0.1.0.  Demo (included) updated to V0.1.2
https://sourceforge.net/projects/lazautoupdate/files/otherpackages/cryptini.zip

BTW, when you get to do SVN links in OPM:
svn checkout svn://svn.code.sf.net/p/cryptini/code/ cryptini-code

or: https://sourceforge.net/p/cryptini/code/HEAD/tree/trunk/latest_stable

[balazsszekely]

Updated CryptINI to V0.1.0.  Demo (included) updated to V0.1.2
https://sourceforge.net/projects/lazautoupdate/files/otherpackages/cryptini.zip

Done. Please test it.

BTW, when you get to do SVN links in OPM:
svn checkout svn://svn.code.sf.net/p/cryptini/code/ cryptini-code
or: https://sourceforge.net/p/cryptini/code/HEAD/tree/trunk/latest_stable

I don't know the exact date. I still have to implement:
  - update from external zip(this will be ready soon)
  - update from SVN
  - voting system
Patches are always welcome!

[JuhaManninen]

  - update from external zip(this will be ready soon)

I think the whole idea is fishy. Which one is the master file, OPM repo or external? Very confusing. Please see my earlier writing about the same thing.
There should be one place for the master file with no ambiguity.

Yes, I also wrote about an external JSON and a package. Then my idea was a totally external package with no copy in the repo.

  - voting system
Patches are always welcome!

The server side requires more than patches. It must be deployed to a server machine. I think you should ask about it from Marc and Vincent in advance.
Anyway, nice to see you have energy also for that part.

[minesadorada]

Done. Please test it.

Looking good.  Version shows as 0.1.0.  Thanks.

[minesadorada]

I think the whole idea is fishy. Which one is the master file, local or external? Very confusing. Please see my earlier writing about the same thing.
There should be one place for the master file with no ambiguity.

I agree with you about the system 'as is' but let's wait and see what GetMem has in mind for package maintainers.  There are quite a few options available.

SVN could only work if package authors maintain a 'stable branch' for instance.  There needs to be a protocol established for packages offered by OPM both for new authors and maintainers that avoids versioning issues.

Once Laz 1.8 is released, a packaging versioning mistake in OPM could propagate to many many users simultaneously.

Re: External json - why can't an external json be periodically checked then downloaded and  merged with the master copy (along with the package) if its version is better?  This could be (semi)-automatic.