Forum > Third party

ct4laz

(1/33) > >>

JuhaManninen:

--- Quote from: avra on January 02, 2018, 01:38:37 pm ---Since I have now updated ct2laz to be able to convert latest CT 6.30+ projects and packages, I would like to discuss first what would be the ideal way to go for ct4laz. The general idea would be to use ct4laz from OPM so I write in this thread, but if you feel more like starting a new thread to avoid polution, please say so. Here is the general concept of ct4laz that I would like to discuss:

--- End quote ---
Avra, I move this to a new thread here. This is specific to your ct4laz repository and not about OPM in general. The replies would be buried to the general comments.


--- Quote ---8 )   Automating conversion process is so far successful with ct2laz. However there might be a need in the future to apply patches to some components. I see that you do it with some OPM packages. Do you have it automated in some way?

--- End quote ---
This last point raises my alarms a little bit.
The main goal of OPM is to provide released packages. Fixing bugs and applying patches is the duty of package maintainers. The people who want to use a development version of a package can still do so by downloading from the master revision control repo.
Ok, sometimes this rule is fuzzy. There are projects without releases and OPM must use the development version then. Yes, Synapse may also be an exception to the rule. I don't know.

However if you create a process for OPM to patch the packages then you practically fork those projects and force GetMem to become a maintainer of those forked projects. No, it is not sustainable in the long run.
If a project needs a bug fix, then send a patch to the original project.
If the patch is ignored, then put pressure on its maintainer. Explain how important it is for OPM and how it is used by thousands of people (or something).
If the project's maintainer is busy, then offer yourself as a co-maintainer with commit access.
If things are still in halt, then fork the project and become its maintainer. This way the process is not tied to OPM which is meant for delivering packages, not maintaining them.

JuhaManninen:
This was the avra's post in "Online Package Manager" thread :


--- Quote from: avra on January 02, 2018, 01:38:37 pm ---Hello GetMem,

if you remember we had initial discussion about central repo for CodeTyphon components which I would like to call ct4laz:
http://forum.lazarus.freepascal.org/index.php/topic,38514.msg261943.html#msg261943

Since I have now updated ct2laz to be able to convert latest CT 6.30+ projects and packages, I would like to discuss first what would be the ideal way to go for ct4laz. The general idea would be to use ct4laz from OPM so I write in this thread, but if you feel more like starting a new thread to avoid polution, please say so. Here is the general concept of ct4laz that I would like to discuss:

1 )   I would use ct2laz to convert all CT packages and CodeOcean examples (excluding ORCA ones, because of the potential licensing problem)
2 )   I would host everything from conversion process on new ct4laz bitbucket git repo, similar as ct2laz is hosted now
3 )   I am thinking about using one repo for everything, using current directory structure of CT packages and CodeOcean examples. However, I am not yet familiar with registering packages to OPM, so I have to ask if this is a good approach? Once repo is established, one by one CT packages would be added to OPM.
4 )   I would like to host everything from the conversion process, although probably only pl_* packages and related CodeOcean examples are interesting for OPM. They should probably be downloaded together in one shot. Would that be a problem for OPM?
5 )   For clear distinction and giving credits to PilotLogic I would like to keep their pl_ prefix for each package originating from CT. OPM can show some other real name to the user, but I would like to keep their "original" package names. The reason for this are users who, for one reason or another (usually bug fixes or cross platform improvements), need to use original pl_* packages even when Lazarus and OPM provide native ones (ct2laz allows this possibility during the conversion process).
6 )   You already have several CT packages in OPM. I think that they should go into ct4laz and have "original" pl_ prefix in their package name, but I clearly would like to know your opinion on this matter. I would give you write access to ct4laz repo if you want, of course.
7 )   Using Synapse in OPM gave me a headache because of 2 versions. Some packages are using stable and some are using trunk. Trouble comes when I need several packages using different Synapse packages. It gets solved after manual fixing everything to use trunk Synapse, but that would be too much for an average OPM user. It also gives trouble when converting CT packages which use pl_synapse, because I have to tell ct2laz to convert all to trunk OPM Synapse package (stable is too old and not compatible). If I tell ct2laz not to convert pl_synapse then I have to install pl_synapse and that again conflicts with any OPM Synapse already installed. You see the problem. Ideally there would be only one Synapse package in OPM and that would be using Synapse trunk. What do you think about this?
8 )   Automating conversion process is so far successful with ct2laz. However there might be a need in the future to apply patches to some components. I see that you do it with some OPM packages. Do you have it automated in some way?

Any idea or improvement to this imaginary concept is most welcome.

--- End quote ---

wp:
I fear a central repository of all CT packages for usage in Lazarus is a very bad idea and will end up in a terrible mess. I am not talking of these packages which are unique to CT, but of that vast majority which are just copies of Laz packages. Units and packages are renamed, but the classes are named like their Laz counterparts. There is nothing to prevent a user from installing a CT package and the corresponding Laz package simultaneously: now each class of these packages will be duplicate and, therefore, the package will not be functional any more, not sure - but maybe even Lazarus will stop working.

Moreover, these CT packages which duplicate Laz packages are less maintained than the Laz packages. Looking into the CT forum I see almost no activity, compared to forum and bugtracker here, and bug reports are usually commented as "we will look into this issue", and then, when Laz has fixed the issue, the fix will appear in the next CT version.

ct2laz is a great tool to make those CT packages available which don't have a Laz counterpart. But this is a tool for somebody who knows what he is doing. A repository of ready-to-use CT package will cause more trouble than benefits. Instead of this I'd pick those CT-only packages, convert them to Laz and distribute them in OPM. An example is the package "astronomy" which is now in OPM, but originally was a CT-only package.

But - this must be clear: All these packages will not be maintained, and I see the future that OPM will end up like CCR: initially lots of enthusiasm, but a few years later, when the excitment has gone, it will just accumulate dead code. What if FPC introduces another code-breaking feature? Or Laz moves functions to other units again? Or code marked as deprecated is finally removed? These things usually are easily fixed, but somebody must do it. Who? Who will take care of the more than hundred packages in OPM when this happens? With CT in there it will be even worse! (well, I am very pessimistic today...)

lainz:
I've seen BGRAControls in CT, they have units that I've removed and replaced with new one (components).

So they don't have it up to date, also some days ago I've added new components, and these just as wp said are a copy on CT nothing new or fixes of nothing.

So copy these that are unique and open source somewhere and if someone mantains it or not it's a problem of course.

GetMem:
Hi all,

In the mean time other people also replied. Just to make clear, we are talking about packages that are unique to CT. Packages that was developed by Pilot Logic or converted from old Delphi sources and maintained only by them. It make no sense to re-add packages already available in Lazarus.


--- Quote ---1 )   I would use ct2laz to convert all CT packages and CodeOcean examples (excluding ORCA ones, because of the potential licensing problem)
--- End quote ---
That would be great. Thanks. But we should add to OPM only the packages not available anywhere else. In fact this is what I did until now.

--- Quote ---2 )   I would host everything from conversion process on new ct4laz bitbucket git repo, similar as ct2laz is hosted now
--- End quote ---
Bitbucket is perfrectly fine or any other version control system for that matter. 

--- Quote ---3 )   I am thinking about using one repo for everything, using current directory structure of CT packages and CodeOcean examples. However, I am not yet familiar with registering packages to OPM, so I have to ask if this is a good approach? Once repo is established, one by one CT packages would be added to OPM.
--- End quote ---
After the conversion is complete, every package must be added to OPM manually, I will do this myself, luckily the process is automated, it takes no longer then 1 min. in average for each package.

--- Quote ---4 )   I would like to host everything from the conversion process, although probably only pl_* packages and related CodeOcean examples are interesting for OPM. They should probably be downloaded together in one shot. Would that be a problem for OPM?
--- End quote ---
No problem at all. The release cycle of CT packages are slow, when new version of a particular package is avaliable, after a quick conversion it can be added again to OPM.

--- Quote ---5 )   For clear distinction and giving credits to PilotLogic I would like to keep their pl_ prefix for each package originating from CT. OPM can show some other real name to the user, but I would like to keep their "original" package names. The reason for this are users who, for one reason or another (usually bug fixes or cross platform improvements), need to use original pl_* packages even when Lazarus and OPM provide native ones (ct2laz allows this possibility during the conversion process).
--- End quote ---
I don't mind adding pl_ prefix to packages, hower we should also add the original developers to the "Author" field(lpk file). I did this for every CT package available in OPM + I also added PilotLogic Software House to give cretids for the conversion, maintanance. I spent a lot of time seraching for original authors, although in most cases a hint is available somewhere in a txt file.

--- Quote ---6 )   You already have several CT packages in OPM. I think that they should go into ct4laz and have "original" pl_ prefix in their package name, but I clearly would like to know your opinion on this matter. I would give you write access to ct4laz repo if you want, of course.
--- End quote ---
Yes I converted the packages manually, it was really painful and slow. With CT4Laz the whole process should take much less. Again I have nothing against pl_prefix in the package name. 

--- Quote ---7 )   Using Synapse in OPM gave me a headache because of 2 versions. Some packages are using stable and some are using trunk. Trouble comes when I need several packages using different Synapse packages. It gets solved after manual fixing everything to use trunk Synapse, but that would be too much for an average OPM user. It also gives trouble when converting CT packages which use pl_synapse, because I have to tell ct2laz to convert all to trunk OPM Synapse package (stable is too old and not compatible). If I tell ct2laz not to convert pl_synapse then I have to install pl_synapse and that again conflicts with any OPM Synapse already installed. You see the problem. Ideally there would be only one Synapse package in OPM and that would be using Synapse trunk. What do you think about this?
--- End quote ---
As Juha mentioned above, the main goal of OPM is to provide released packages. However in the case of synapse I think we can make an exception. The release cycle is so slow that almost six years passed since the latest stable version. I'm gonna fix this issue soon.

--- Quote ---8 )   Automating conversion process is so far successful with ct2laz. However there might be a need in the future to apply patches to some components. I see that you do it with some OPM packages. Do you have it automated in some way?
--- End quote ---
This is usually done by the "update feature"(http://wiki.freepascal.org/Online_Package_Manager#Update_a_package ). When a package is not maintained or the release cycle is slow I do it myself.

Navigation

[0] Message Index

[#] Next page

Go to full version