Closed Barsonax closed 4 years ago
Is there any equivalent in NuGet 5, which we can query for project "status quo"
If I understand correctly you want a list of all packages needed including all dependencies. Nuget provides a API for this and the PackageConfig.xml
itself can be used as input for this. With some logic you can then figure out what packages to install and what to uninstall.
I believe the nuget class we need for this is called DependencyResource or similar.
If I understand correctly you want a list of all packages needed including all dependencies.
Ah, no, not the needed ones - I might have explained it all a bit convoluted. I'll try again, in short.
This is what we have now:
PackageConfig.xml
: Which Duality packages the project wants.Source\Packages
via NuGet API: Which (NuGet) packages are installed right now.What we need now, since the packages folder no longer seems to play that role in NuGet:
PackageConfig.xml
: Which Duality packages the project wants.???
: Which (NuGet) packages are installed right now.That second ???
part is what I meant. Is there some sort of NuGet-managed package lock file or something else that tells you what is actually installed right now? If not, we could probably write our own in some bookkeeping file inside the Source\Packages
folder.
Rebased on the latest master. Changes are now down from 39 to 9 files :)
???: Which (NuGet) packages are installed right now.
Isn't this something duality could provide based upon the files present in the plugin folder? Might need to split it up to prevent ambiguity between packages and dll's that were just copied there?
Not depending on nuget for this would make future updates easier so design wise this be would be preferable. Nuget doesn't have logic for this anyway so the only way is to add another layer in between.
In that case, I'd probably go with an InstalledPackages.xml
inside Source\Packages
that gets updated immediately after an individual package install / uninstall is complete. That way, NuGet would be out of the equation for bookkeeping here, and we don't risk falling into ambiguity traps when checking plugin, lib and sample files. For a first iteration, behavior would also be equal to what we have right now, which is nice. Could also be an opportunity to clean up a bit of local package setup code.
I can look into this, provided I manage to carve out some time, fingers crossed 😄
Yup might be better that you look into this particular part.
In the current commit of this PR there is still the package config on the nuget side that is not needed anymore I think btw.
Okay, so right now I'm the bottleneck for moving this forward, but I'll try to briefly summarize what I think needs to be done here before we can merge:
PackageSetup
, including local folder paths.InstalledPackages.xml
in Source\Packages
to reflect which (NuGet) packages are currently installed, to replace the previous "local repository" mechanic that was based simply on existing folder structures. (See above)PackageConfig.xml
changes and restart.PackageCache
is gone and re-introduce some equivalent if it's too bad.I'll report back with progress and help requests as soon as I get to it.
@ilexp do you still have time to implement this? If not maybe we should make it clear that somebody else can take it over.
Not that I have much time lately though...
@ilexp do you still have time to implement this? If not maybe we should make it clear that somebody else can take it over.
Good call - I'm honestly a bit overwhelmed with real life stuff lately and since I'm clearly the bottleneck here, I'd be happy to let someone take over, and try to help with advice.
Upgraded to nuget 5.4 so we stay up to date. Currently working on getting the unit tests working properly again. Turns out we still referenced the old nuget 2.14 in the unit tests (FIXED). Also its currently not using the test repository that the unit tests sets up which breaks many tests.
Seems like PackagePathResolver and PackageIdentity truncate the revision number. Meaning a version like 1.0.0.0 will end up as 1.0.0. Seems nuget doesnt want you to use 1.0.0.0? Needs some more research to be sure.
EDIT: nuget is normalizing the version numbers: https://docs.microsoft.com/en-us/nuget/concepts/package-versioning#normalized-version-numbers
Closing this as we have decided to take a different route in #786
Not ready to merge yet. Prerequisites: