search

DelphiPackageManager / PackageManagerRFC

Delphi Package Manager RFC
Apache License 2.0
30 stars 0 forks source link

Single file for all, or one per compiler/platform? #9

Open vincentparrett opened 5 years ago

vincentparrett commented 5 years ago

Should a package file be

  1. A Single file, which contains support for all supported compiler version/platforms supported, or
  2. One file per compiler version/platform combination.

A single file could be quite large, which will impact on performance when installing/restoring from a remote package source, however multiple files would make things more complicated for package creators.

Also, if the package contains binaries, should it contain Debug and Release, or should debug & release be in separate package files?

With Nuget, it uses separate package files for the symbols (pdb's), but with delphi, the symbols are in the dcu's, so perhaps a single file for release and debug would be fine (with release mandatory, debug optional).

landrix commented 5 years ago

+1 One file per compiler version/platform combination and with Debug and Release

casteng commented 5 years ago

I think option 2 is better. The tool can have "prepare package" command to create packages automatically using command line compiler(s).

vincentparrett commented 5 years ago

What about packages that just have source code? That would result in unnecessary duplication of files.

casteng commented 5 years ago

Packages with just source code can be downloaded/unzipped as is. There is no need to compiler or prepare a binary packages. As of release/debug modes - probably debug mode is needed for binary only (say commercial) packages and rarely be available compiled in debug mode. So it can be sorted out as a different package. I.e. com.company.library and com.company.library.debug.

UweRaabe commented 5 years ago

Not sure if this is feasible, but what about creating the download files on the fly depending on the particular request? The library provider uploads all bits and pieces, all supported platforms and versions, debug and release and so on and the download manager takes what is needed and bundles it into a single zip file.

code-kungfu commented 5 years ago

@UweRaabe It could be done, but it would require a fast backend.

UweRaabe commented 5 years ago

We can still tailor the client to handle a list of files for download. That would eliminate the need for creating the zip file.

vincentparrett commented 5 years ago

Bear in mind that the server doesn't exist yet, and probably won't for a while. The reason for having the package zipped is for storage and transport simplicity. Initially, a package feed/source would just be a folder of compressed package files. The file names would be used for the listing. When a package is installed, it would be uncompressed into the package cache folder, and then the various parts referenced from there.

I'm no a fan of having a complicated protocol for the server for downloading parts etc, really the server should be simple, just provide a list of packages/versions available and provide a way to download them. This is pretty much how most other package servers work, and it allows for multiple server implementations (ala nuget.org, myget etc). That would make it possible for example for third party vendors to host their own package feeds.

wlandgraf commented 5 years ago

In my "internal" package manager I use to distribute TMS Business, I have both. For trial versions, there are one package for each Delphi version (with all platforms), but for registered versions there is a single package which applies to all, since it has the source code. The binaries are generated on the fly, upon compilation. I'm willing to share what we have, as I'm interested in adopting this as "official" way to distribute TMS Business components (and maybe all TMS components later).

vincentparrett commented 5 years ago

@wlandgraf I'm definitely interested in seeing what you have.

My concern about compilation on install is it may break or complicate the dependency chain and we end up with lots of these errors.

F2051 Unit X was compiled with a different version of Y

My preference would be for precompiled dcu's etc, but I realise that puts a burden on the package author needing lots of delphi versions installed. For commercial vendors that's always going to be a requirement.

wlandgraf commented 5 years ago

@vincentparrett, how can I show you what I have? Through private e-mail, then you select what can be included here? Regarding compilation, isn't it required to compile things on the fly when all you have is source code? Also, it's precompiled dcu's that can cause those version issues, since dependencies users have in their computer might be different than the ones at compile time in vendor's computer?

jcangas commented 5 years ago

@vincentparrett DelphiVM also allow for source packages. In fact this is how my few customers use it. This way, packages are very light, and DelphiVM compile only the platforms you really use. This also saves a lot of space in local package cache. I never found the problem F2051 Unit X was compiled with a different version of Y This is avoided easily with correct package naming & versioning and a clear output folder structure

vincentparrett commented 5 years ago

@wlandgraf email is fine - vincent @ finalbuilder.com

With regards to compilation issue, when you have a dependency chain is all source, it will be fine. When there are dcu's only somewhere in the chain, that's when things break.

e.g Package VSoft.A requires TMS.X (which supplies source). VSoft ships VSoft.A as dcu's, only - things will get hairy if the user updates TMS.X. When a user is using a dcu only package, they cannot take updates to any dependencies of that dcu only package without also updating it (assuming there is an update).

It's not rocket science, but it's not simple, we just need to work out the rules and make sure they are applied when building packages and using them.

wlandgraf commented 5 years ago

@vincentparrett, ok I will l send it to you. Regarding compilation, isn't it the requirement the same for both dcu and non-dcu? I mean if VSoft.A is dcu only is has to be compatible with TMS.X no matter what. If TMS.X updates, VSoft.A must be updated as well, so that requirement is the same if TMS.X also has source code.

vincentparrett commented 5 years ago

@wlandgraf the rules are almost the same. The exception is when a source package depends on a dcu package, the dcu package can be updated (minor updates at least) and the source package can be recompiled. A dcu package that depends on a source package cannot take updates to the source package without itself being updated. Provided we get the rules right (and enforce them) then it should be fine. Of course this assumes that package authors do the right thing with regards to versioning and compatibility (ie, following semver).