Lazarus Component list

[TurboRascal]

I was thinking of creating a litle (Windows) installer for most CCR packages, so I was wondering where are the packages for installation listed? Specifically, I'd like to make the installed components listed there, as the Lazarus-bundled packages are, instead of having to open them manually file by file...

[typo]

This?

http://sourceforge.net/projects/lazarus-ccr/files/

[TurboRascal]

No, this:

[Glenn]

No, this:

@TurboRascal: Your idea sounds a bit like the one I've have had in the works for a couple of months now
Try take a look in this thread: http://lazarus.freepascal.org/index.php/topic,12408.0.html

Instead of inventing the wheel over and over again, we could team up to create a proper solution, feel free to contact me

[TurboRascal]

Yes, I saw that before, but didn't quite connect your idea and mine then

My original idea I had for some time is to create an offline InnoSetup installer for those components, one similar to the Lazarus installer itself. I thought of it mostly for my own use to make it simpler, and just by the way to help others who'd also find the package useful.

However, why not make it as you proposed, and as I understand it, it would solve installations for other platforms and other components as well, which I find quite interesting.

So, I guess I'm in We should get in touch concerning this...

Now, for whatever solution we create, how do we put installed packages to Lazarus' list of available packages?

[JuhaManninen]

@TurboRascal: ideintf/packageintf.pas defines interfaces to reach the package list. You must dive into Lazarus development a bit if you want to do it properly.
IMO making a Windows-only installer for cross-platform packages is not very clever.

This "distributed package manager" or how to call it, must be tightly integrated with Lazarus.
I understood fppkg is made for similar purposes but is not finished. I must learn more about the subject.
If you guys really decide to work on this, then we should put up a source repository. One choice is a branch in Lazarus SVN server.
I want to participate also.

Juha

[fabienwang]

If we create an online "package repository" with automatic downloads into lazarus,
then we should also setup user reviews and vote system (note between 0 and 5 for example), and also have the most downloaded / most highly rated packages visible easily.

[dblaszijk]

Please see this thread: http://www.mail-archive.com/lazarus@lists.lazarus.freepascal.org/msg12065.html

[Glenn]

I've created a google code project here: http://code.google.com/p/lazarus-core-extensions/

I'm in the process of examining whether the built-in wiki is sufficient or a MediaWiki installation would be better

./Glenn

[JuhaManninen]

I've created a google code project here: http://code.google.com/p/lazarus-core-extensions/
I'm in the process of examining whether the built-in wiki is sufficient or a MediaWiki installation would be better

The wiki should be enough for now. The bigger problem is to get people to write something there.
... and write code ... (there isn't any yet).
How congrete plans you have at this point? Did you look at fppkg? Does it fit into the picture?

Juha

[dblaszijk]

I think there will be only a slim chance of having another package manager approved for Lazarus than fppkg. Fppkg is also planned to be used as package manager for FPC. If I were you I would contact the lead developers for fppkg and discuss this with them. Adding a graphical frontend to fppkg would be a good first step and then comes the tedious part of creating all the packages one by one.

[JuhaManninen]

I think there will be only a slim chance of having another package manager approved for Lazarus than fppkg. Fppkg is also planned to be used as package manager for FPC. If I were you I would contact the lead developers for fppkg and discuss this with them. Adding a graphical frontend to fppkg would be a good first step and then comes the tedious part of creating all the packages one by one.

Yes, a graphical frontend which can use fppkg code as library. It does not need to use the cmd line compiled binary.
I understood fppkg has good base and it makes no sense to "re-invent the wheel". If it has missing features or other problems then it can be improved/forked.
I dare to say the decisions are made by technical quality only, there is no political interest to use a certain program. It means if the package manager is good then it will be accepted. I can commit code myself to whole Lazarus tree now (but I will not commit crap there of course).

The lead developers of fppkg also develop FPC and they are busy. Please remember that there is no lack of "discussion" or "good ideas" but there is a lack of people actually creating good quality code. My experience is that if someone truely shows an effort to create such code, he gets support.

Juha

[dblaszijk]

Yes, a graphical frontend which can use fppkg code as library. It does not need to use the cmd line compiled binary.

What's the benefit of linking fppkg in? Imho it could work just as fine to use the cmd line application. The compiler is also not linked in the IDE is it?

I understood fppkg has good base and it makes no sense to "re-invent the wheel". If it has missing features or other problems then it can be improved/forked.

Why fork? If properly motivated improvements are accepted. I never had any issues having patches committed with fpmake which is the build system from FPC.

I dare to say the decisions are made by technical quality only, there is no political interest to use a certain program. It means if the package manager is good then it will be accepted. I can commit code myself to whole Lazarus tree now (but I will commit crap there of course).

Of course they are technically only. But what is so compilcated about a package manager? It's just a simple app that can download packages from a repository, unzip and build and install. Hardly rocket science. So why need multiple versions in Lazarus and FPC? Using the same packagemanager has the benefit that you can add FPC packages as well on demand using the same UI.

The lead developers of fppkg also develop FPC and they are busy. Please remember that there is no lack of "discussion" or "good ideas" but there is a lack of people actually creating good quality code. My experience is that if someone truely shows an effort to create such code, he gets support.

Very good point indeed. There are a lot of initiatives but there's no one actually producing something. That is why I would stick to fppkg, because it's also used for FPC and Joost has already done work on it to get it working for Lazarus it will be the best starting point.

On the other hand, I'm no core developer, so I would ask on the mailing list first before choosing one way or the other. Having a package manager is a very much appreciated feature. Just don't make the mistake to start off wrong and waste your time because the core team already decided on some strategy.

[JuhaManninen]

First a fix: I wanted to write "but I will NOT commit crap there of course". Nasty errors   

I agree with you basically about using the existing code. I was rather anticipating the practical problems that happen inevitably when creating code based on some other (not finished) code.
Sometimes you need to change the other code. If you send a patch for its maintainer and wait until he finds time to look at it and commit, your own work gets blocked for many days.
So, in reality you change the code without asking its author and then experiment with it. That is a fork already. And if many people work on the same code, also the forked part must be copied to the common repository. There is nothing wrong with it. Many of the experimental features will be thrown away and later the efforts can be united.
I didn't propose a competing forked solution but more a temporary fork for pragmatic reasons.

The GUI frontend may indeed be easy. But, there were also high-flying ideas with cross-compiling etc.
I don't know enough details yet to know how much work it is.

Juha

[dblaszijk]

First a fix: I wanted to write "but I will NOT commit crap there of course". Nasty errors   

I thought so 

I agree with you basically about using the existing code. I was rather anticipating the practical problems that happen inevitably when creating code based on some other (not finished) code.
Sometimes you need to change the other code. If you send a patch for its maintainer and wait until he finds time to look at it and commit, your own work gets blocked for many days.
So, in reality you change the code without asking its author and then experiment with it. That is a fork already. And if many people work on the same code, also the forked part must be copied to the common repository. There is nothing wrong with it. Many of the experimental features will be thrown away and later the efforts can be united.
I didn't propose a competing forked solution but more a temporary fork for pragmatic reasons.

Ah ok, I call that a branch, but the outcome is the same. Yeah sure why not.

The GUI frontend may indeed be easy. But, there were also high-flying ideas with cross-compiling etc.
I don't know enough details yet to know how much work it is.

Cross compiling has nothing to do with fppkg, but with fpmake as far as I know. BTW for more details on fppkg please check the wiki.