VSoft Technologies BlogsVSoft Technologies Blogs - posts about our products and software development.https://www.finalbuilder.com/resources/blogsDPM Package Manager - Progress updatehttps://www.finalbuilder.com/resources/blogs/postid/842/dpm-package-manager-progress-updateDelphi,DPMWed, 24 Feb 2021 10:46:15 GMT <p>In December 2019, I <a href="/resources/blogs/introducing-dpm-a-package-manager-for-delphi" target="_blank">blogged</a> about a package manager for Delphi that I am working on. This post is a progress update that shows where it's at and what's left to do to get to v1.</p> <h3>DPM Recap</h3> <p> For those not familiar with what I am trying to achieve here, I highly recommend reading my original <a href="/resources/blogs/delphi-package-manager-rfc" target="_blank"> Delphi Package Manager RFC</a> post. In that post I detailed my ideas, and some of the challenges that Delphi presents when compared to other development environments. </p> <p> In December 2019, the bare bones of DPM were there. We had a command line tool and that was it. We were able to create packages, install packages (and their dependencies) and restore them (restore ensures all referenced packages are present). Oh and we could list the available packages in our package feed (a folder). </p> <h3>IDE Integration</h3> <p> In the last 13 months there were around 175 commits to the DPM repository. In that time I have added an IDE plugin (that works in Delphi XE2 to 10.4). This involved the creation of several custom controls (I wasn't able to bend any existing ones to work how I wanted it to). </p> <p> In addition to the work in the project repository, I also published <a href="https://github.com/vsoftTechnologies/" target="_blank">several useful libraries</a> that I needed for this project. DPM is now bootstrapped, to build DPM you need DPM, as it requires several libraries that are referenced as dpm packages. </p> <p> In Nov 2020 I published the first alpha release that included an installer (code signed by VSoft Technologies) for installing both the command line tool and the IDE plugin (single installer, you can choose which IDE versions to install for). The installer allows you to install for the current user, or for all users (requires elevation to install). </p> <img src="/blogimages/vincent/dpm-progress/installer.png"> <p></p> <p> I also did a zoom presentation about DPM to the Melbourne chapter of the Australian Delphi Users Group - a recording of that (long) presentation can be found <a href="https://www.youtube.com/watch?v=TjVAMLfhgLo" target="_blank">here</a>. </p> <p> Adding IDE support for DPM was a massive undertaking. I had very little experience in developing Delphi IDE plugins (using the tools api) - and there were lots of subtle changes between delphi versions, getting things working correctly in 12 versions of Delphi was not easy. In particular, with the later versions of Delphi IDE that use VCL themes, getting things to look right (ie like a native part of the IDE) was a challenge. </p> <img src="/blogimages/vincent/dpm-progress/dpm-ide.png"> <p></p> <p>The above image shows the installed packages for one of the projects in the project group, you get to this view by right clicking on the project node, or the DPM Packages node in the Project tree. </p> <p>Note the view only shows the directly installed packages, not the transient dependencies - those you can see in the project tree under the DPM Packages node.</p> <p>Before you can use DPM in the IDE, you need to configure a package source (a folder where your package files will live)</p> <p>This can be done fron the command line</p> <pre>dpm sources add -name=local -source=path to the folder you created</pre> <p></p> <p>Or from the IDE Settings</p> <img src="/blogimages/vincent/dpm-progress/dpm-settings.png"> <p></p> <h3>Compile during install</h3> <p> The most recent updates added support for compiling packages during first install. Packages need to declare how to build in their dspec file, and dpm will use that and call msbuild to compile the packages if needed. DPM also records a bill of materials file (package.bom) in the package cache so that it can tell whether the package needs to be recompiled or not. </p> <p>On first install, packages that are being compiled during the install process will take a little longer, but on subsequent installs or restores, the process is almost instant (a few ms). </p> <p> Prior to adding this feature, building dpm on our Continua CI build agents took 13 minutes, much of which was taken up with compiling the dpm packages that it references (in particular, earlier versions of Delphi were very slow with spring4d). Since updating dpm on our agents with the new version, the entire build process for DPM (console app and 12 versions of the IDE plugin and the installer) takes less than 2 minutes. </p> <img src="/blogimages/vincent/dpm-progress/dpm-build-times.png"> <p></p> <h3>Missing features</h3> <h4>Project group support</h4> <p> When installing packages, the dependency resolution code does not know about other projects in the project group, or what packages and versions they reference. This will be a problem for packages that include design time components that need to be loaded - the IDE can only load 1 version of a design time package. This is what I am currently working on. </p> <h4>Design time packages</h4> <p>DPM does not currently install design time packages into the IDE. This is dependent on project group support, so it's next on the list after project group support.</p> <h4>Package Updates</h4> <p>The ability to detect when package updates are available and make it easy to install those updates. There's an Updates tab in the IDE but it's non functional at this time.</p> <h4>Package Repository</h4> <p>In it's current state, DPM only supports folder based package feeds. This works fine, but it does have some limitations</p> <ul> <li>Limted search abilities - limted to searching on the package filenames.</li> <li>You have to download packages to a folder.</li> <li>Package Authors have to host the package files somewhere (mine are under releases on their github projects).</li> </ul> <p>I have made a start on the Package Repository, but not a lot of progress since I'm focusing on the client site right now.</p> <h3>Q & A</h3> <h4>Is it usable?</h4> <p>In it's current state, it's only usable for non visual libraries. As I mentioned, the DPM projects all use DPM themselves, and we have DPM actions in FinalBuilder for running the Pack and Restore commands. </p> <p>If you use any of my open source libraries like DUnitX, Delphi Mocks etc, I have created packages for all of those libraries, and also created mirror projects (just for hosting the package files) for some other popular libraries like Spring4D. </p> <p>I would encourage library authors in particular to take a look and provide feedback.</p> <h4>Where can we find it?</h4> <p>DPM is an open source project on <a href="https://github.com/DelphiPackageManager/DPM" target="_blank">GitHub</a>, the installer can be found under <a href="https://github.com/DelphiPackageManager/DPM/releases" target="_blank">Releases</a> (under each release, there is an Assets dropdown section).</p> <img src="/blogimages/vincent/dpm-progress/installer-location.png"> <p></p> <h4>What versions of Delphi does it support?</h4> <p>Delphi XE2 to 10.4.2 - note that we compile with the latest updates installed for each compiler version. </p> <h4>Why is it taking so long?</h4> <p>Yes, someone asked that recently! This is a side project, free and open source. My primary focus is on running my business and working on our products (that keeps the lights on).</p> <h4>Can we sponsor the project?</h4> <p>Not right now, however it's something I'll look at in the future. </p> <h4>Can we help?</h4> <p>Absolutely. Fork the project on GitHub and clone it to your dev machine and spend some time getting to know the source code. Before making any pull requests, create an issue on github to discuss your ideas and make sure we on the same wavelength!</p>842Advice for Delphi library authorshttps://www.finalbuilder.com/resources/blogs/postid/841/advice-for-delphi-library-authorsDelphi,DPMWed, 24 Feb 2021 00:57:00 GMT <p>We use many third-party Delphi libraries to build FinalBuilder and Automise, and that brings plenty of issues when upgrading compiler versions. I've been using Delphi since 1995, both as a developer and as a component vendor, I have learned a thing or two about creating libraries that I would like to share. These are all ideas that make life easier for users, and make it easy to migrate from one version of Delphi to another.</p> <p>There's no hard and fast rules on how Delphi Libraries are <i>supposed to be</i> structured, these are just my preferences and things I have learned over the years. Hopefully this will help new and existing library authors.</p> <h3>Folder Structure</h3> <p>Keep the Source and the Packages in separate folders, this makes it easier to find the correct packages to compile, e.g : <pre>\Source \Packages \Demos</pre> </p> <p>Under Packages, create a folder for each compiler version your library supports, e.g: <pre>\Packages\Rad Studio XE8 \Packages\Rad Studio 10.0 \Packages\Rad Studio 10.1</pre> </p> <h3>Package Names</h3> <p>Please, <b>do not</b> put the Delphi version in the package project names.</p> <h4>Bad!!!</h4> <pre>MyProjectRun_D10_4.dproj MyProjectDesign270.dproj</pre> <h4>Good</h4> <pre>MyProjectRun.dproj MyProjectR.dproj MyProjectDesign.dproj MyProjectD.dproj</pre> <p></p> <p>Why not put the compiler version in the package project name you might ask? Well the answer is that it makes upgrading compiler versions a major pain for users who link their projects with Runtime Packages (yes, that includes us).</p> <p>The reason is that when you compile a package, it creates a packagename.dcp file and that is what your project references. So, if your package name is MyPackageRun_D10_4 then that is what will be added to projects that use it.</p> <pre class="brush:delphi; toolbar:false;"> package MyOwnPackage; //... requires rtl, vcl, MyPackageRun_D10_4, AnotherPackage_Sydney, YetAnotherPackage_D104, // ... </pre> <p></p> <p>When Delphi 10.5 comes out, guess what the user has to do to upgrade their projects.... Yep, replace that all those package references with 10.5 versions (and the multitude of suffixes). Multiply that by a number of projects and a number of libraries (each with potentially multiple runtime packages) and you can see why this might be a pain.</p> <p>Now you might say, but we don't want 15 versions of MyPackageRun.bpl laying about on users machines, and you would be right. The solution to this is a feature that has been around since Delphi 6 (2001) - <a href="http://docwiki.embarcadero.com/RADStudio/Sydney/en/Compiler_directives_for_libraries_or_shared_objects_(Delphi)" target="_blank">LIBSUFFIX</a>.</p> <img src="/blogimages/vincent/advice-for-d/libsuffix.png" alt="LIBSUFFIX"> <p></p> <p>Setting LIBSUFFIX (on the Description section of project settings) will append the specified suffix to the BPL file name. So a suffix of _D10_4 will result in a package :</p> <pre>MyPackageRun_D10_4.bpl</pre> <p></p> <p>however, the DCP file will still be generated as :</p> <pre>MyPackageRun.dcp</pre> <p></p> <p>Remember it's the dcp file that our projects reference (for linking) - so by keeping the dcp file the same for all delphi versions, upgrading to a new compiler version just got a whole lot easier!</p> <p>So when Delphi 10.5 comes out in the future, all I need to do is install the packages, no changes to my projects.</p> <p><b>Update</b> : Someone pointed out that Delphi 10.4.1 support LIBSUFFIX $(Auto) - this will use the Delphi defined PackageVersion - which for 10.4 is 270. This is a nice addition as it makes upgrading the package projects simpler. Of course if you don't like the PackageVersion suffix and use a custom one, then this is not for you.</p> <h3>Use Explicit rebuild, not Rebuild as needed</h3> <p>Have you ever encountered the error <pre>E2466 Never-build package 'XXX' requires always-build package 'YYY'</pre> What this means is, a package, set to Expicit rebuild, references another package, set to 'Rebuild as needed', and it's a pain in the proverbial. Rebuild as needed is also referred to as Implicit Build - in dpk's you will see it as <pre>{$IMPLICITBUILD ON}</pre> If that "Rebuild as needed" package is not part of your project group, guess what, you get to waste time closing and opening projects trying to get it to compile. </p> <p>I'm sure someone will correct me on this, but I cannot see a good reason to have "Rebuild as needed" set. I suspect this is a hangover from before the Delphi IDE allowed you to specify <a href="http://docwiki.embarcadero.com/RADStudio/Sydney/en/Project_Dependencies" target="_blank">Project Dependencies</a> and it slows down builds. </p> <h3>Use Search Paths for includes</h3> <p>I often see includes with either hard coded paths, or relative paths like this :</p> <pre class="brush:delphi; toolbar:false;"> {$I '..\..\MyDefines.inc'} </pre> <p>That's great, if the installer delivers the files in the right place - but they often don't - I hit this issue today, where the package just would not compile. I eventually figured out that the relative path was wrong. </p> <p>There's a simple fix for this, and that is to remove the path in the $I statement, and use the Project Search Paths feature instead. </p> <img src="/blogimages/vincent/advice-for-d/searchpath.png" alt="Search Paths"> <p></p> <p>I have also seen libraries where there are mulitple copies of the include file and they are slightly different!</p> <h3>Mark packages as Runtime only or Designtime only</h3> <p>Some libraries have their packages marked as "Runtime and Designtime" (the default) - the impact of this is only minor, but it's a pet peeve of mine. The Delphi IDE (in recent versions at least) provides a nice indication of whether packages are runtime or designtime in the project tree, and for designtime packages, whether they are installed. </p> <p>This makes it simple for me to determine which ones need to be installed or not.</p> <p>Not Installed</p> <img src="/blogimages/vincent/advice-for-d/not-installed.png" alt="Not Installed"> <p>Installed</p> <img src="/blogimages/vincent/advice-for-d/installed.png" alt="Installed"> <p></p> <h3>Summing up</h3> <p>One of the major reasons people do not upgrade Delphi versions is because it's too hard to deal with the third party libraries and all the changes required just to get to the point of compiling. That eventually results in a lack of Delphi sales which results in a lack of investment in Delphi which feeds back into.... well you get the idea ;)</p> <p>Making third party libraries easier to work with in Delphi has been a bit of a crusade for me, I've been <a href="/resources/blogs/delphi-package-manager-rfc">working on this for a while now</a>, and I'm getting closer to a solution - <a href="https://github.com/DelphiPackageManager/DPM">DPM - A package manager for Delphi</a> - if you are a library author, I encourage you to take a look. For examples on how to create a package spec (dspec) take a look at our open source projects <a href="https://github.com/vsoftTechnologies/">https://github.com/vsoftTechnologies/</a> </p> 841Introducing DPM - a Package Manager for Delphihttps://www.finalbuilder.com/resources/blogs/postid/837/introducing-dpm-a-package-manager-for-delphiDelphi,DPM,Open SourceThu, 12 Dec 2019 09:41:00 GMT<p>Back in Feb 2019, I <a href="/resources/blogs/delphi-package-manager-rfc" target="_blank">blogged</a> 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.</p> <p>DPM is an <b>open source</b> package/library manager for Delphi XE2 or later. It is heavily influenced by Nuget, so the cli, docs etc will seem very familiar to nuget users. Delphi’s development environment is quite different from .net, and has different challenges to overcome, so whilst I drew heavily on nuget, DPM is not identical to nuget. I also took a close look at many other package managers for other development eco systems.</p> <h2>What is a Package Manager</h2> <p>A package manager provides a standard for developers to share and consume code. Authors create packages that other developers can consume. The package manager provides a simple way to automate the installation, upgrading or removal of packages. This streamlines the development process, allowing developers to get up and running on a project quickly, without needing to understand the (usually adhoc) way the project or organization has structured their third party libraries. This also translates into simpler build/CI processes, with less ‘compiles on my machine’ style issues.</p> <h2>Who and Why</h2> <p>DPM’s initial developer is Vincent Parrett (author of DUnitX, FinalBuilder, Continua CI etc). Why is discussed in <a href="http://www.finalbuilder.com/resources/blogs/delphi-package-manager-rfc">this blog post</a>.</p> <h2>DPM Status</h2> <p>DPM is still in development, so not all functionality is ready yet. At this time, it's at the stage where we I would encourage library authors to take a look and play with it and provide feedback (and perhaps get involved in the development). It's very much at a minimum viable product stage. Potential users are of course welcome to look at it and provide feedback, it's just that, well, there are no packages for it yet (there's some test packages in the repo, and I'll be creating ones for my open source libraries). .</p> <h3>What works</h3> <ul> <li>Creating packages</li> <li>Pushing packages to a package source.</li> <li>Installing packages, including dependencies</li> <li>Restoring packages, including dependencies.</li> </ul> <h3>How do I use it</h3> <p>The documentation is at <a href="http://docs.delphipm.org">http://docs.delphipm.org</a></p> <p>See the <a href="http://docs.delphipm.org/get-started/getting-started.html">getting started guide</a>.</p> <p>The command line documentation can be found <a href="http://docs.delphipm.org/commands.html">here</a>.</p> <p>The Source is on GitHub <a href="https://github.com/DelphiPackageManager/DPM">https://github.com/DelphiPackageManager/DPM</a></p> <h3>Is DPM integrated into the Delphi IDE</h3> <p>Not yet but it is planned. If you are a wiz with the open tools api and want to contribute then let us know.</p> <h3>Is there a central package source</h3> <p>Not yet but it is planned. At the moment, only local folder based <a href="http://docs.delphipm.org/concepts/sources.html">sources</a> are supported. The client code architecture has a provision for http based sources in the future, however right now we are focused on nailing down the package format, dependency resolution, installation, updating packages etc.</p> <h3>Is my old version of delphi supported</h3> <p>Maybe, <a href="http://docs.delphipm.org/compiler-versions.html">see here</a> for supported compiler versions. All target <a href="http://docs.delphipm.org/platforms.html">platforms</a> for supported compiler versions are supported.</p> <h3>What about C++ Builder or FPC</h3> <p><a href="http://docs.delphipm.org/compiler-versions.html">see here</a></p> <h3>Does it support design time components</h3> <p>Not yet, but that is being worked on.</p> <h3>How does it work</h3> <p>See <a href="http://docs.delphipm.org/concepts/how-it-works.html">this page</a></p> 837Delphi Package Manager RFChttps://www.finalbuilder.com/resources/blogs/postid/777/delphi-package-manager-rfcDelphi,DPM,Open SourceMon, 16 Jul 2018 01:58:00 GMT<p>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.</p> <p>Other developement environments, like the .net and javascript eco systems, recognised and solved this problem many years ago. Getting a .net or javascript project up an running, in a new working folder or new machine is trivial.</p> <p>With Delphi/Rad Studio, it's much harder than it should be. In consulting work, I've made it a point to see how clients were handling third party code, and every client had a different way. The most common technique was... well, best described as adhoc (with perhaps a readme with the list of third party products to install). Getting that code compiling on a CI server was a nightmare.</p> <h2>Existing Package Managers</h2> <p>Embarcadero introduced their GetIt package manager with XE8, and the GetIt infrastructure has certainly has made the installation of RAD Studio itself a lot nicer. But as a package manager for third party libraries, it comes up short in a number of areas.</p> <p>There is also Delphinus, which is an admirable effort, but hasn't gotten much traction, possibly due to it being strongly tied to github (you really need github account to use it, otherwise you get api rate limiting errors).</p> <p>Rather than pick apart GetIt or Delphinus, I'd like to outline my ideas for a Delphi package manager. I spend a lot of time working with .net (nuget) and javascript (npm, yarn), so they have very much influenced what I will layout below.</p> <p>I have resurrected an old project (from 2013) that I shelved when GetIt was announced, and I have spent a good deal of time thinking about package management (not just in Delphi), but I'm sure I haven't thought of everything, I'd love to hear feedback from people interested in contributing to this project, or just potential users.</p> <h2>Project Ideals</h2> <p>These are just some notes that I wrote up when I first started working on this back in 2013, I've tried to whip them into some semblance of order for presentation here, but they are just just rough outline of my ideas.</p> <h3>Open Source</h3> <p>The Project should be Open Source. Of course we should welcome contributions from commercial entities, but the direction of the project will be controlled by the community (ie users). The project will be hosted on GitHub, and contributions will be made through Pull Requests, with contributions being reviewed by the Steering committee (TBA).</p> <h3>Public Package Registry</h3> <p>There will be a public website/package server, where users can browse the available packages, and package authors can upload packages. This will be a second phase of the project, with the initial phase being focused on getting a working client/package architecture, with a local or network share folder for the package source.</p> <p>The package registry should not be turned into a store. Once a public package registry/server is available, evaluation packages could be be allowed, perhaps by providing a fee (web hosting is not free). Commercial vendors will of course be able to distribute commercial packages directly to their customers, as the package manager will support hosting of packages in a shared network or local directory. Package meta data will include flags to indicate if the packages are commercial, eval or free/open source. Users will be able to decide which package types show up in their searches.</p> <h3>Package Submission</h3> <p>Package submission to the public registry should be a simple process, without filling in and signing and faxing of forms! We will follow the lead of nuget, npm, ruby etc on this. There should be a dispute process for package names, copyright infringement etc. There will also be the ability to assign ownership of a package, for example when project ownership changes.</p> <p>Package Authors will be able to reserve a package prefix, in order to prevent other authors from infringing on their names or copyrights. For example, Embarcadero might reserve Emb. as their prefix, TMS might reserve TMS. as theirs. (of course I'm hoping to get both on board). The project will provide a dispute resolution process for package prefixes and names.</p> <h2>Delphi specific challenges</h2> <p>Delphi presents a number of challenges when compared to the .net or nodejs/javascript world.</p> <h3>Compatibility</h3> <p>With npm, packages contain source (typically minimized and obfuscated) which is pure javascript. Compatibility is very high.</p> <p>With Nuget, packages contain compiled (to .NET IL) assemblies. A package might contain a few different versions, that target different the versions of the .net framework. Again, compatibility is pretty good, an assembly compiled against .net 2.0 will work on .net 4.7 (.net core breaks this, but it has a new compatibility model, netstandard).</p> <p>If we look at Delphi, binary compatibility between Delphi compiler versions is pretty much non existent(yes, I know about 2006/7 etc). The dcu, dcp and bpl files are typically only compatible with the version they were compiled with. They are also only compatible with the platform they were generated for (so you can't share dcu's between 32 and 64 bit windows, or between iOS and Android). So we would need to include binaries for each version of Delphi we want our library to support. This also has major implications for library dependencies. Where as npm and nuget define dependencies as a range of versions, a binary dependency in Delphi would be fixed to that specific version. There is a way to maintain binary compatibility between releases, provided the interfaces do not change, however exactly what the rules are for this is hard to come by, so for now we'll ignore that possibility.</p> <p>That limits the scope for updating to newer versions of libraries, but that can also be overcome by including the source code in package, and providing on the fly compilation of the library during install. My preference would be for pre-compiled libraries, as that speeds up the build process (of course, since that's an area I have a particular interest in). In Continuous Integration environments, you want to build fast and build often, rebuilding library code with each CI build would be painful (speaking from experience here, 50% of time building FinalBuilder is building the third party libraries).</p> <p>There's also the consideration of Debug vs Release - so if we are including binaries, compiled for Release would be required, but Debug optional? The size of a package file could be problematic. If the package contains pre-compiled binaries for multiple compiler versions, it could get rather large. So perhaps allow for packages that either support a single compiler version, or multiples? The compilers supported would be exposed in the package metadata, and perhaps also in the package file name. Feedback, ideas around this would be welcome.</p> <p>Package files would be (like with other package managers), a simple zip file, which include a metadata (xml) file which describes the contents of the package, and folders containing binaries, source, resources etc. Packages will not contain any scripts (ie to build during install) for security reasons (I don't want to be running random scripts). We will need to provide a way to compile during install (using a simple dsl to describe what needs to be done), this still needs a lot of thought (and very much involves dependencies).</p> <h3>Library/Search Paths</h3> <p>Say goodbye to the IDE's Library path. It was great back in 1995, when we had a few third party libraries and a few projects and we just upgraded the projects to deal with library versioning (just get on the latest). It's simply incompatible with the notion of using multiple versions of the same libraries these days.</p> <p>I rarely change major versions of a library during the lifespan of a major release of my products, I might however take minor updates for bugfixes or performance improvements. The way to deal with this is simply to use the Project Search path. Project A can use version 1 of a library, Project 2 can use version 9, all quite safely (design time components do complicate this).</p> <p>Where a project targets multiple platforms, installing a package should install for all platforms it supports, but it should be possible for the user to specify which platforms they need the package installed for.</p> <h3>Design time Component Installation</h3> <p>The Rad Studio IDE only allows one version of a design time package to be installed at a time. So when switching projects, which might use different versions of a component library, we would need a system that is aware of component versions, and can uninstall/install components on the fly, as projects are loaded.</p> <p>I suspect this will be one of the biggest project hurdles to overcome, it will requires someone with very good open tools api knowledge (ie, not me!).</p> <h3>Dependencies</h3> <p>Libraries that depend on other libraries will need to specify those dependencies in a metadata file, such that they can resolved during installation. As I mentioned above, binary compatibility issues make dependency resolution somewhat more complicated, but not insurmountable. The resolution algorithm will need to take into account compiler version and platform. The algorithm will also need to handle when a package is compiled from source, for example, binary only packages should not be allowed to depend on source only packages (to ensure compatibility). If we end up with install time package compilation, then some serious work will be needed on the dependency tree algorithm to work our what else needs to be done during install (ie, do any dependencies need to be recompiled?).</p> <p>This is certainly more complicated than other platforms, and a significant amount of work to get right (ps, if you think it isn't, you haven't considered all the angles!)</p> <h2>General Considerations</h2> <h3>Package Install/Restore</h3> <p>The user should be able to choose from a list packages to install. When installing the package, this would be recorded either in the dproj, or a separate file alongside the drproj. The install process will update the project search paths accordingly. Package meta data would control what gets added to the search paths, my preference would be for 1 folder per package, as that would keep the search path shorter which improves compile times.</p> <p>When a project is loaded, the dproj (or packages config file) would be checked, and any missing packages restored automatically. This should also handle the situation where a project is loaded in a different IDE version.</p> <h3>Security</h3> <p>We should allow for signing of packages, such that the signatures can be verified by the client(s). Clients should be able to chose whether to only allow signed packages, or allow signed and unsigned, and what to do when signature verification fails. This will allow users certainty in the authenticity and integrity of the package (ie where it comes from and whether it's been modified/tampered with).</p> <h2>Clients</h2> <p>It is envisaged that will be at least 2 clients, a command line tool, and a Rad Studio IDE plugin. Clients will download packages, add those packages to project/config search paths. A local package cache will help with performance, avoiding repetitive package downloads and also reduce disk space demands. The clients will also detect available updates to packages, and package dependency conflicts.</p> <h3>Command line Client</h3> <p>The command like tool will be similar to nuget or npm, which provide the ability to create packages, install or restore missing packages, update packages etc. The tool should allow the specification of compiler versions and platforms, as this is not possible to detect from the dproj alone. This is where the project is currently focused (along with the core package handling functionality).</p> <h3>RAD Studio IDE Client</h3> <p>An IDE plugin client will provide the ability to search for, install, restore, update or remove packages, in a similar manner to the Nuget Visual Studio IDE support (hopefully faster!). This plugin will share the core code with the the command line client (ie, it will not call out to the command line tool). I have not done any work on this yet (help wanted).</p> <h2>Delphi/Rad Studio Version Support</h2> <p>Undecided at the moment. I'm developing with XE7, but it's possible the code will compile with earlier versions, or be made to compile with minor changes.</p> <h2>Summary</h2> <p>Simply put, I want/need a package manager for Delphi, one that works as well as nuget, npm, yarn etc. I'm still fleshing out how this might all work, and I'd love some feedback, suggestions, ideas etc. I'd like to get some people with the right skills 'signed up' to help, particularly people with open tools api expertise.</p> <h2>Get Involved!</h2> <p>I have set up a home for the project on GitHub - <a href="https://github.com/DelphiPackageManager/PackageManagerRFC">The Delphi Package Manager Project - RFC</a>. We'll use issues for discussion, and the wiki to document the specifications as we develop them. I have created a few issues with things that need some dicusssion. I hope to publish the work I have already done on this in the next few days (needs tidying up).</p> 777