Lazarus
Programming => Packages and Libraries => Lazarus Extra Components => Topic started by: TurboRascal on April 15, 2011, 01:39:00 am
-
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...
-
This?
http://sourceforge.net/projects/lazarus-ccr/files/
-
No, this: ;)
-
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 :)
-
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?
-
@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
-
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.
-
Please see this thread: http://www.mail-archive.com/lazarus@lists.lazarus.freepascal.org/msg12065.html
-
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
-
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
-
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.
-
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
-
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.
-
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
-
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.
-
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.
And people should realize this is a quite long term process. It is easy to imagine some simple global memory structure and derive from that, but the many targets, tweaks options, and ways to install are a problem.
But Joost has finally started to roll it out. And while there are problems, one shouldn't forget that the move from handcrafted makefiles to fpcmake also took two periods of about half an year (first Sebastian?, then Peter) to introduce.
-
How congrete plans you have at this point? Did you look at fppkg? Does it fit into the picture?
I've done done some research and trying to lay out plans for the project.
I did take a look at fppkg and it fits mostly into the picture :)
However, a lot of changes has to be made to fppkg if the wish-list should be fulfilled.
- I might branch fppkg and implement the ideas, as I find the changes too radical until they're been approved by the fp team :)
I'll publish a roadmap on the google code page in one of the forthcoming days. when time allows.
Best regards
Glenn
-
I created a (trivial) lazarus plugin for fppkg. Extending this to Lazarus needs a bit of work, but seems doable I would say.
http://lists.lazarus.freepascal.org/pipermail/lazarus/2011-May/062910.html
-
I created a (trivial) lazarus plugin for fppkg. Extending this to Lazarus needs a bit of work, but seems doable I would say.
http://lists.lazarus.freepascal.org/pipermail/lazarus/2011-May/062910.html
Looks interesting :)
Currently I'm not at my dev laptop, so I'll take a look at the code later today :)
-
I created a (trivial) lazarus plugin for fppkg. Extending this to Lazarus needs a bit of work, but seems doable I would say.
Now many people are either doing a similar installer or planning to do it.
The efforts should be united and synchoronized.
Can you Darius (dblaszijk) give your code to the Glenn's repository? Or do you have another repository?
Juha
-
Now many people are either doing a similar installer or planning to do it.
Oh yeah? Who is doing something then? I only see vague ideas to be honest. And even those were about forking fppkg or creating even a new system. My patch is a graphical front-end to fppkg with later some extensions to Lazarus, nothing more.
The efforts should be united and synchoronized.
No question about it, that is why I asked for a review first and then have it commited to the components folder in Lazarus SVN.
Can you Darius (dblaszijk) give your code to the Glenn's repository? Or do you have another repository?
It's out there on the mailinglist, see the link I put up in my previous message. Anyone is free to do whatever he/she likes with it.
-
Darius, people were planning to write an installer because they didn't know you were already writing one. At least I didn't know.
Yes, I was speculating with (temporary) forks and such before there was any code. It was useless.
Still, I am thinking how to better utilize the code from new developers. As you know sending patches for Lazarus can be a slow process.
There is nothing wrong with an external repository if it makes things easier.
Juha
-
This stuff is like I mentioned earlier trivial (because of fppkg) and it only took me about two hours to come up with the first GUI version. Now I'm almost finishing the basic outline of the software. Instead of controlling the command line application the FPC core team agreed to move some of the fppkg sources to ./packages so I will be able to link to them directly. In a couple of days I will release a version that will be fully functional. In the mean time I will put up evaluation patches on the bug tracker. So anyone genuinely interested can join. See: http://bugs.freepascal.org/view.php?id=19335
I will also need to create some patches to fppkg because I want to add support for keywords, categories and support level.
@Juha, I don't mind that it will take some time before the patches get approved and committed. Typically this does not impact the quality negatively, but rather the opposite.
-
I found another couple of hours to finish the first version. I'm quite happy how it works, although it can always work better. At least all the functionality is implemented correct now.
Please check out en report your findings.
-
I comitted the code in Lazarus SVN. Let's move the discussion to the Lazarus mailinglist ;)