DPM Support

[vincentparrett]

Hi Cesar

Any chance you could consider publishing DPM packages for dext? I have attached the dspec files I created (designed to live in a \dpm folder in the repo).

I created multiple package definitions with (I hope) the correct dependencies (please check).

Dext.AI.dspec.yaml
Dext.AST.dspec.yaml
Dext.Core.dspec.yaml
Dext.EF.Components.dspec.yaml
Dext.EF.Core.dspec.yaml
Dext.Events.dspec.yaml
Dext.Hosting.dspec.yaml
Dext.Net.dspec.yaml
Dext.Testing.dspec.yaml
Dext.UI.dspec.yaml
Dext.Web.Core.dspec.yaml
Dext.Web.Hubs.dspec.yaml

To create the package files, download and install the dpm client from github and then either use the dpm cli

dpm pack Dext.Core.dspec.yaml -o=c:\outputfolder

for each package - or use the DSpecCreator gui to pack (and upload) the packages.

To publish packages, you need to sign up on the website, verify your email address (enable 2fa if you didn't use a social login), then create an api key to use with the cli or with DSpecCreator.

dpm push Dext.*.dpkg -source=dpm -apiKey=xxxxxx

Vincent.

[cesarliws]

Hi @vincentparrett ,

Thank you so much for reaching out and for taking the time to create all these dspec files for Dext! I truly appreciate the effort and your initiative. Having a centralized, NuGet/npm-like package manager is something I've envied in other ecosystems for years, and DPM is exactly what the Delphi community needs.

I would love to have Dext available on DPM. However, I currently face a significant technical bottleneck regarding the build matrix.

Dext is designed to support multiple Delphi versions and various target platforms (Windows, Linux, Android, iOS, macOS). As an open-source maintainer, my local infrastructure is quite lean: I actively run Delphi Sydney (for my daily job) and Delphi 13 (where I develop Dext), keeping only the specific target platforms I strictly need installed to save resources.

To publish binary packages on DPM, I would need to compile the .dpkg files for this entire version/platform matrix. If I publish only what I can build locally (e.g., just D13 and Sydney for Windows and Linux), I risk creating a frustrating Developer Experience (DX) for users who expect a full package but find it lacks support for other Delphi versions and platforms. This is why historically I've relied on source-based distribution, as it naturally delegates the build matrix to the user's environment.

Is there a way we can bridge this gap collaboratively?

1. Does DPM support (or plan to support) a source-only distribution model, where the package simply delivers the source code and the build happens on the client side during dpm install?
2. Alternatively, do you have a recommended GitHub Actions CI/CD workflow that can automate the compilation of these packages across the different Delphi versions and platforms, so I don't need to maintain a local build farm?

I really want to support the DPM ecosystem, but I need an automated or source-first approach to make it sustainable on my end.

Let me know your thoughts!

Best regards,
Cesar Romero

[vincentparrett]

Hi Cesar

1. yes, and that is what those dspec.yaml files do - the pack command (or pack button in DSpecCreator) basically zips up the specified files (defined in the dspec). The source is compiled on the user's machine when they install the packages.

2. I don't use github actions (since I sell on premise CI software!) - however I am sure that GH actions can run simple commands - I guess you would need a local GH agent installed to run windows - dpm client is windows only.

I have XE2-13.0 installed on my dev machine, and on all our CI agent machines (just copied the bits needed and the registry keys) - it's so easy to accidently break code for earlier versions with delphi, something as simple as calling an overload that doesn't exist, or array initializers (that is a common one I see a lot of), inline variables etc. The sad fact is that most libraries that I have looked at to get published on dpm are not in a good state - they have packages for some random versions, but those don't actually compile. When working on DPM I have D13.0 and XE2 open all the time. I code in 13.0 but always build/test with XE2 as well.

[cesarliws]

Hi @vincentparrett ,

First of all, a massive mea culpa on my end! I completely misunderstood the DPM architecture, and I have to admit, my Delphi-wired brain played tricks on me.

Whenever I read "build package" or "create package" in the DPM documentation, I immediately assumed it meant compiling the source code into binary distribution files (like .bpl or .dcp). I even chatted with a Belgian friend about it recently, and he had the exact same misunderstanding! It might partly be a language barrier since English isn't my first language, but it seems to be a very common assumption among Delphi developers given our history with the word "packages".

A friendly suggestion: It might be incredibly helpful to add a highly visible note in the DPM documentation explicitly stating that DPM is a source-first package manager—meaning dpm pack simply zips the source files, and compilation happens entirely on the user's local machine during installation. That simple clarification will definitely prevent other open-source maintainers from panicking about their build matrices!

Regarding the syntax compatibility you mentioned, you are absolutely right. Interestingly, just a few weeks ago, I did a massive refactoring and completely removed all var inline usages to improve backward compatibility. I also created a formal compatibility matrix for Dext, which you can check here: https://github.com/cesarliws/dext/blob/main/Docs/Delphi_Compatibility_Matrix.md

Our recommended baseline is now Delphi 10.1 Berlin. This is primarily because our ORM relies heavily on the [Weak] attribute to safely manage reference counting and prevent memory leaks. Our Tier 1 (Main) support spans from 10.4 Sydney to 12 Athens.

I will read the documentation to make the necessary adjustments to the .dspec files you kindly created to enforce this minimum compiler version constraint. Once that's done, I will create my account and push them to DPM.

Thanks again for your patience, the DSpec files, and for building such an essential tool for the community!

Best regards,