I wish people would stop dividing their packages into 1000 individual .LPKs...

[Akira1364]

Maybe that modular design style worked for Delphi packages, but with Lazarus it's basically a guaranteed recipe for circular dependencies and orphaned PPUs. I mean, if your "design time" package is just going to reuse all the units from your "run time" package, but the .PAS files for both are all in the same folder to begin with, then just put everything in one package! GLSceneLaz, I'm looking at you... anyone else find this sort of thing to be a major antagonist in the plot of their Lazarus development story? 

[Leledumbo]

Actually, the splitted packages could be a good idea to cover both WYSIWYG programmers and pure hand coding programmers. It's however the design time package should depend on runtime package instead of including the same unit files. Design time package can use the runtime package files and then register components only.

[Akira1364]

Yes, I certainly agree. My point here is that that's more than often NOT the case.

[Graeme]

I mean, if your "design time" package is just going to reuse all the units from your "run time" package, but the .PAS files for both are all in the same folder to begin with, then just put everything in one package!

NO, that is a terrible idea! Do you actually understand the difference between a runtime package and a design-time package?

Lets take something I know - OnGuard (security components). Originally everything was lumped into one Lazarus design-time package. The problem - I couldn't use it with fpGUI, because the design time package references Lazarus IDE and LCL units, and I was coding a pure fpGUI only application. Technically the OnGuard components are totally GUI Toolkit independent, but because of using the design-time package, it forced a LCL dependency.

So what I did was to split the OnGuard into two packages. A runtime package which is 100% non-GUI. This means anybody can use the runtime package with fpGUI or even Console or WebServer applications. Then I created a design-time package, and added the runtime package as a required dependency, and added a unit that contains the code that allows it to register on the Lazarus IDE's component palette (something I never require in my projects). So now any type of project (LCL, fpGUI, Console, Web etc) can use OnGuard components.

This problem is moot if you don't use Lazarus Packages, because then you would simply set the Unit Search Path for your project and instantiated any classes you want via code. Though I have seen badly designed components that have artificial (unnecessary GUI) dependencies, which need to be refactored first.

[Graeme]

My point here is that that's more than often NOT the case.

Then those developers have no clue regarding the difference between runtime and design-time packages. They should be educated on the difference.