Vincent Parrett

The GUI projects have issues, I don't use them and haven't worked on them.. not sure when they broke but will try at least the fix the VCL one. FWIW, the console tests project and the console examples project both compile and run fine. You really don't need a gui to run unit tests, except when developing, and for that I use TestInsight.

Memory leak reporting in delphi unit tests are difficult to do accurately, as the test framework is using the same memory manager as the tests. Not sure who this is aimed at "Anyway the devs seem not using test project at all, it is even not compilable in current state." but I can assure you as a dev on DUnitX and many other projects I use unit testing every day. There is some debris in the dunix repo, mostly in the fmx area due to the lack of compatibility between fmx versions (and I don't use or work on fmx stuff). It's not easy to keep everything in a compiling state for a ton of different delphi versions, especially when I don't have every version installed.

300Kb might not sound like much, but when it's part of a 3.1MB page (this page) and 66 requests each with 350ms latency (I'm in Australia), then it does matter. I remember posting about this before, nothing has changed, these forums are still really slow for me. Functionally they are fine, quite usable, but they could definitely use some optimisation, like combining/bundling js files so that less requests are made. This alone would be a major improvement.

I guess the project wizard needs some work. I'll try and schedule some time but have a pretty full plate right now.

The readme is a bit out of date, embarcadero did contribute some changes to make it work on mobile and linux.

Thanks, didn't get the automated one, but go the one you sent shortly after your reply.

How do existing users get this?

https://www.finalbuilder.com/resources/blogs/managing-delphi-version-info-with-finalbuilder

Most likely, but IANAL.

"One time" so I get to install one more time and then I'm up shit creek?

AFAIK there's no way to deactivate or deregister an install.

WTF Embarcadero, you are just alienating the few paying customers you have left. If you use activation as a licensing mechanism, you MUST offer deactivation or a means to move licenses, without requiring support involvement. Seriously pissed off by this move, the cow is almost milked dry!

Delphi/Rad Studio desperately needs a proper package/library/component manager. A package manager provides a standardized way of consuming third party libraries. At the moment, use of third party libraries is very much adhoc, and in many cases this makes it difficult to move projects between machines, or to get a new hire up and running quickly. Other development eco systems, like Ruby, .net and Javascript, recognised and solved this problem many years ago. Getting a Ruby, .net or Javascript project up an running, in a new working folder or new machine is trivial. Delphi Package Manager RFC

@timfrost Thanks for your feedback. Funnily enough, I do exactly what you do with my array of third party packages right now, but it's not really optimal (even with a great tool like FinalBuilder 😉 ). Taking updates to packages is still problematic/manual and error prone, and this is really still a global thing rather than per project. I want to open a project in the IDE, and know that all my dependencies are present and correct, just we do now with nuget. As you would expect from a company that sells a CI Server, we do lots of CI builds, and building all the third party code from source with every build is painful to say the least, it almost doubles our build times. Building them once on install would speed up the build process dramatically. Of course there will still be the option to just use the source, and an option to turn off compilation on install. Authors/Vendors will have the option to choose what they distribute, source code, pre-compiled binaries or both, the option to compile on install (which users can override). This project is going to take some time, there are so many variables, every author/vendor does things differently, so we'll need to consider all the variables and come up with something that hopefully works for the majority. I don't have the power to force this on anyone, nor would I want to. I'm just trying to create some order out of the current random chaos that exists now.

@Stefan Glienke weren't you working on something like that? That is something I'd pay for!

@Stefan Glienke It's shame you feel that way, I was thinking the spring framework would be a perfect candidate for something like this, and in fact I've been using it while playing with ideas for the package specification. Yes, design time package unloading will be a problem, most likely what we'll do is on package restore, if there is any change in the design time components installed we'll offer to restart the IDE. Of course this is not an issue for command line or CI builds, as we don't need to install components, just ensure the project can be built with the correct search paths. This project will have lots of technical hurdles, but I still think we can do better than what we have now.

@Remy Lebeau That does still work, however it still doesn't allow you to install multiple versions of the same package, which makes life difficult. For example, on v7 I might use packageA.1.0.0 and on v8 I might use packageA2.2.0 - I don't want to update v7 to use the newer packageA, for a bunch of possible reasons. There are (as others have pointed out) problems with unloading packages, lots of third party packages don't clean up properly and unloading causes IDE instability.

@Thijs van Dien In my experience the signing feature in Innosetup was fragile, mostly because if the timestamping failed (due to the server not responding, happens a lot) then you had to recompile the whole thing again. Better to do the signing and timestamping seperate from the innosetup step (using signtool), and the signing and timestamping separately so you can retry when timestamping fails.

If you also timestamp the signature, the exe will be signed permanently. If you skip timestamping the signature will no longer be valid once the certificate expires. This blog post covers codesigning & timestamping

As far as I can tell, it's pretty much like GetIt, ie a global package installer? What I'm proposing is handling per project dependencies, ie nothing is global.

I'm open to contributions that would allow supporting FPC, but my primary target is what I use, Delphi.

@Eli M. Thanks. We're some way from that yet, but when we get to the IDE integration we'll be looking for people with UI skills to contribute. Right now I want to focus on the structure of packages/libraries etc, how they are defined, naming conventions, etc.

Chocolatey is Nuget repurposed for installing applications, not for installing code libraries. It's also a .net application. As much as I love .net/c#, I think a delphi package manager should be written in delphi.

I'm open to suggestions when it comes to package naming conventions, but it's going to take a lot to convince me to allow running of scripts. Running random scripts that haven't been vetted for security is major issue. Perhaps a better option would be to include some sort of dsl that has some pre-defined functionality (like copy files etc).

Uwe, I'm definitely open to contributions, there's no way I can achieve the desired result by myself (I still have to earn a living!). It's a complex task, and there are a lot of moving parts and design decisions to be made. I expected package unloading to be an issue. Package Magician looks interesting.. hopefully we can get you on board, I haven't really played with the open tools api much for many years. Github link fixed.