Vincent Parrett

Not strictly speaking, but not relying on the scope names does actually speed up compilation. Then there's the different code styles in thousands of units created over 20 years, I'm a bit OCD I guess and want to apply the same standard across all my code!

@Uwe Raabe thank! I'll take a look at it tomorrow.

Not sure if this is still the case, but hi color icons were not supported by brcc. I switched to using rc years ago because of this and never bothered switching back, so maybe that's been fixed (but I would not be surprised if it hasn't been).

There's no easy answer to this question, and it's one I've battled with for 20+ years. If it's a trivial change (< 10 min to code and test) and I think it's relevant (not all customer feature requests are, we have to evaluate how they apply to all users) I'll often just go ahead and do it immediately after reading the ticket. It's appreciated by customers, but a double edged sword, the more you do it the more they ask 😉

Back in Feb 2019, I blogged about the need for a Package Manager for Delphi. The blog post garnered lots of mostly useful feedback and encouragement, but until recently I could never find a solid block of time to work on it. Over the last few weeks I've been working hard to get it to an mvp stage. https://www.finalbuilder.com/resources/blogs/introducing-dpm-a-package-manager-for-delphi

Good point... I wrote that message (in the core) months ago, before it was actually working so my mindset was probably a bit pessimistic back then 😉

Made some progress today on IDE integration, screenshot below of my first attempt at doing a dpm restore in the IDE plugin. Very much early days with the IDE integration, but it was still a punch the air kinda moment when it worked first time!

The package cache is accessible from projects without modification, but that's not my primary use case... in fact I can't see why you would want to do that. As for stand alone and being easily backed up.. I've not found making my vs.net projects stand alone necessary at all. I use distributed version control (git and mercurial) which is backed up (along with the copies already on our CI servers and other dev machines) - and our nuget packages are backed up (by nuget.org and our own backups for packages we haven't published). I've not tried using npm pack on a non package project, but does it really back up all the dependencies, I don't think it does.

Hi All Any Open Tools api experts here? I'm working on an ide expert that needs to be notified when a project is opened and closed. I have something working IOTAProjectFileStorageNotifier, however when project groups are opened I can't tell because the ProjectLoaded method is never called for it. Is there a better way? Ideally I'd like to be notified before a project/group is loaded (I just need the filename). thx

Thanks @Uwe Raabe - IOTAIDENotifier was exactly I needed - first ever dpm restore on project load Still plenty to do but the basics are working

Thanks @Uwe Raabe I'll take a look at that tomorrow.

Global as (by default at least) 1 copy of the package on the file system, but not global as installed on the ide library path. Not sure what you mean by packing the whole project?

The only thing DPM adds to the search path (via a single variable) is the paths each package requires, as specified by the package authors, and only for the packages that project is actually using. How is that any different from manually managing the search paths for a library?

I don't expect that DPM will be for everyone or that everyone will switch every project to it. I spent months reviewing feedback from my RFC post, studying other package managers and working to understand the limitations that delphi imposes before really getting stuck into dpm (I originally started on it in 2013, but shelved it when getit was announced). I think that I have a reasonable solution (or at least it will be when it's done) that provides consistency (which is the main requirement) and is performant. I've answered a few emailed questions about performance, in the example dproj info I posted earlier, this is what a restore looks like when the package cache is empty : I:\Github\DelphiPackageManager\DPM\TestPackages\TestProject>dpm restore .\TestProject.dproj Delphi Package Manager - Version : 0.1.1.0 © 2019 Vincent Parrett and Contributors License - http://www.apache.org/licenses/LICENSE-2.0 Attempting restore on [.\TestProject.dproj] for [Win32] Starting dependency resolution... Resolving dependency : VSoft.A.0.1.5->VSoft.B [0.0.1,0.0.4] selected : VSoft.B.0.0.4 Resolving dependency : VSoft.A.0.1.5->VSoft.C [0.0.3,0.0.7] selected : VSoft.C.0.0.7 Resolving dependency : VSoft.B.0.0.4->VSoft.D [0.0.6,0.0.10] selected : VSoft.D.0.0.9 Resolving dependency : VSoft.C.0.0.7->VSoft.D [0.0.1,0.0.8] conflict - selected version : VSoft.D-0.0.9 does not satisfy [0.0.1,0.0.8] overlapping range found : VSoft.D-[0.0.6, 0.0.8] Resolving dependency : VSoft.C.0.0.7->VSoft.D [0.0.6, 0.0.8] selected : VSoft.D.0.0.8 Dependency resolution done in 220ms Downloading package [VSoft.A-XE7-Win32-0.1.5] from [i:\dpmfeed] Package [C:\Users\vincent.OFFICE\AppData\Roaming\.dpm\packages\VSoft.A-XE7-Win32-0.1.5.dpkg] added to cache. Downloading package [VSoft.B-XE7-Win32-0.0.4] from [i:\dpmfeed] Package [C:\Users\vincent.OFFICE\AppData\Roaming\.dpm\packages\VSoft.B-XE7-Win32-0.0.4.dpkg] added to cache. Downloading package [VSoft.D-XE7-Win32-0.0.8] from [i:\dpmfeed] Package [C:\Users\vincent.OFFICE\AppData\Roaming\.dpm\packages\VSoft.D-XE7-Win32-0.0.8.dpkg] added to cache. Downloading package [VSoft.C-XE7-Win32-0.0.7] from [i:\dpmfeed] Package [C:\Users\vincent.OFFICE\AppData\Roaming\.dpm\packages\VSoft.C-XE7-Win32-0.0.7.dpkg] added to cache. This is what it looks like when the packages are already cached. I:\Github\DelphiPackageManager\DPM\TestPackages\TestProject>dpm restore .\TestProject.dproj Delphi Package Manager - Version : 0.1.1.0 © 2019 Vincent Parrett and Contributors License - http://www.apache.org/licenses/LICENSE-2.0 Attempting restore on [.\TestProject.dproj] for [Win32] Starting dependency resolution... Resolving dependency : VSoft.A.0.1.5->VSoft.B [0.0.1,0.0.4] selected : VSoft.B.0.0.4 Resolving dependency : VSoft.A.0.1.5->VSoft.C [0.0.3,0.0.7] selected : VSoft.C.0.0.7 Resolving dependency : VSoft.B.0.0.4->VSoft.D [0.0.6,0.0.10] selected : VSoft.D.0.0.9 Resolving dependency : VSoft.C.0.0.7->VSoft.D [0.0.1,0.0.8] conflict - selected version : VSoft.D-0.0.9 does not satisfy [0.0.1,0.0.8] overlapping range found : VSoft.D-[0.0.6, 0.0.8] Resolving dependency : VSoft.C.0.0.7->VSoft.D [0.0.6, 0.0.8] selected : VSoft.D.0.0.8 Dependency resolution done in 21ms I only showed the Win32 platform for brevity, but each other platform takes the same time. Of course when we eventually have http based package sources, downloading packages will take a bit longer. At the moment it's all single threaded so there's plenty of room for improving performance in the future if needed.

The package cache has a single expanded (ie unzipped) copy of a package version, only for versions that you have used and only when you ask for them. Then you would have 2 copies 😉 At some point you have to reference the location of the source/lib files, I have tried to do it in a manner that will work across multiple machines, no matter where the project is. You are free to change the location of the PackageCache, it might actually be advisable if your C drive is like mine, always full! DPM adds this to the top of the project file : <PropertyGroup> <ProjectGuid>{D07E7230-728D-4BB3-AC4E-EBFA414C5503}</ProjectGuid> <!-- snipped --> </PropertyGroup> <PropertyGroup> <DPMCompiler>XE7</DPMCompiler> <DPMCache Condition="'$(DPMCache)' == ''">$(APPDATA)\.dpm\packages</DPMCache> <DPM>$(DPMCache)\$(DPMCompiler)\$(Platform)</DPM> <DPMSearch Condition="'$(Platform)'=='Win32'">$(DPM)\VSoft.A\0.1.5\src;$(DPM)\VSoft.B\0.0.4\src;$(DPM)\VSoft.D\0.0.8\src;$(DPM)\VSoft.C\0.0.7\src;</DPMSearch> <DPMSearch Condition="'$(Platform)'=='Win64'">$(DPM)\VSoft.A\0.1.5\src;$(DPM)\VSoft.B\0.0.4\src;$(DPM)\VSoft.D\0.0.8\src;$(DPM)\VSoft.C\0.0.7\src;</DPMSearch> </PropertyGroup> This sets up the DPMSearch property for use in the search path. For now we are just adding it to the base config, not 100% if we can add it to all, that might be something we leave for the user. Note that the DPMCache property can be overriden by an environment variable as well. <PropertyGroup Condition="'$(Base)'!=''"> <DCC_UnitSearchPath>$(DPMSearch);$(DCC_UnitSearchPath)</DCC_UnitSearchPath> </PropertyGroup> To store which package references we use, dpm adds this to the ProjectExtensions section <ProjectExtensions> <DPM> <PackageReference id="VSoft.A" platform="Win32" version="0.1.5"/> <PackageReference id="VSoft.A" platform="Win64" version="0.1.5"/> </DPM> </ProjectExtensions> Note that we only have PackageReferences for VSoft.A, however the DPMSearch also has VSoft.B/C/D as those are dependencies of VSoft.A - the install/restore process works this out, downloads and extracts any missing packages and then updates the DPMSearch properties. There's still a lot of work to do with DPM - I'm working on compilation support (optional compile on install) so that builds are done using dcu's rather than the source (faster builds), design time package installation, IDE integration (restore during project load), improving the dependency resolution algorithm. I would love for people to jump in and help, even just code reviews looking for obvious bugs.

It's one copy (the default), unless you want it to be per project. As @David Heffernan said, using different versions if a library for different projects or different branches is quite common and something I do all the time (and with delphi it's painful to manage). As for the size of the JCL, it could probably be split into smaller packages (I don't use it due to it's propensity to pull in a bunch of units for 1 function).

I have created packages for most of my delphi open source projects (not DUnitX, that needs some tidying up) They listed here : https://github.com/DelphiPackageManager/DPM/issues/2

How do you manage upgrading libraries. Once you upgrade for one project, you have to upgrade for every project, that's the nature of global libraries. The "overhead" of installing packages is really quite small, and you can do it incrementally. DPM does not use the library path, but that doesn't mean you still cant. FWIW, one of my reasons for working on dpm is probably somewhat selfish, but 90% of the problems FinalBuilder customers have with compiling delphi projects are related to the library path. I'm hoping that dpm will provide a standard way to work with libraries, so the whole issue of compiles on one machine, not on the other becomes a thing of the past (I can spend my time working on other things!). There are other benefit to not using the library path is the compiler doesn't have to trawl through every installed library even when the project doesn't use them, which makes for slower compile times. It's early days, there's still a lot to do on the project, including IDE integration, which will make working with it a lot simpler. Stay tuned.

Thanks Packages are downloaded and extracted into a package cache folder, which is configurable, and then added to the search path of the project. I have no plans for using the global library path. Packing the whole project with deps - not planned. Delphinus is very different to DPM so not sure how that would work. Installing from a repo.. maybe, but would need to figure out versioning. Not planning to look at this any time soon, but if someone wants to contribute I'm open to it.

On windows 10, this may be a permissions issue. Applications that were launched elevated are not visible to applications that are not elevated.

If you run them without TestInsight do they complete OK? Also if you are using the version of DUnitX that shipped with delphi Berlin then I'd recommend grabbing the latest from github to test with. https://github.com/vsoftTechnologies/dunitx

Digitally signing the installers and binaries may help, but we do that and still get the occasional false positive. We submit the false positive report and it typically resolves itself in a few days (except for windows defender, that takes ages).

I think it was done because every contributor was editing in a different version of delphi, which then changed the dproj file and broke it for older versions.

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.