You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Choco packages can list dependencies in the nuspec included in the nupkg.
The choco stdout also contain a list of dependencies as they are being processed ; if the choco stdout is being read as a stream, this could allow 'real-time' UI for showing the dependencies.
The choco logs also contain the dependency info.
There is also the ability for choco packages to install multiple packages, and optionally skip some based on custom logic in the nupkg. It should be relatively easy to snapshot/monitor the windows installed software list to see what was installed during each Fudge entry.
It would be wonderful if the dependency info was stored in a "Fudgefile.snapshot" (arbitrary suffix to try to describe what it would be). While it is very unlikely the snapshot file would initially be re-usable on any different computer, and therefore isnt a .lock, it would be great to be able to use it when rebuilding on an identical system, such as a CI VM, so Fudge can report when there are changes to the dependencies. In the coala repos, we would have at least two different snapshot files, one for AppVeyor and one for Travis Windows CI.
For ordinary users, likely the snapshot from one user omits some packages which were installed previously, and another user would find they are missing and commit the improved snapshot file.
I expect long term, if anyone is interested, the snapshot file could become a lock file, by adding constraints to each entry to indicate when that dependency is active. The most obvious constraint in lock files (e.g. by gems, pip, npm) is OS, and that would likely apply here, but more likely as Windows OS versions.
The text was updated successfully, but these errors were encountered:
For the choco dependencies which are declared in the nuspec, perhaps a quicker partial solution is to offer to write the detected dependencies into to the Fudgefile above the entry which installed them.
Until Fudgefile supports version ranges (#44), it is effectively acting like a lock file.
The most obvious constraint in lock files (e.g. by gems, pip, npm) is OS [& versions]
Another one is Powershell version, much like PYTHON_VERSION from https://www.python.org/dev/peps/pep-0496/, as some extra dependencies may be needed only to provide backwards compatibility.
Choco packages can list dependencies in the nuspec included in the nupkg.
The choco stdout also contain a list of dependencies as they are being processed ; if the choco stdout is being read as a stream, this could allow 'real-time' UI for showing the dependencies.
The choco logs also contain the dependency info.
There is also the ability for choco packages to install multiple packages, and optionally skip some based on custom logic in the nupkg. It should be relatively easy to snapshot/monitor the windows installed software list to see what was installed during each Fudge entry.
It would be wonderful if the dependency info was stored in a "Fudgefile.snapshot" (arbitrary suffix to try to describe what it would be). While it is very unlikely the snapshot file would initially be re-usable on any different computer, and therefore isnt a
.lock
, it would be great to be able to use it when rebuilding on an identical system, such as a CI VM, so Fudge can report when there are changes to the dependencies. In the coala repos, we would have at least two different snapshot files, one for AppVeyor and one for Travis Windows CI.For ordinary users, likely the snapshot from one user omits some packages which were installed previously, and another user would find they are missing and commit the improved snapshot file.
I expect long term, if anyone is interested, the snapshot file could become a lock file, by adding constraints to each entry to indicate when that dependency is active. The most obvious constraint in lock files (e.g. by gems, pip, npm) is OS, and that would likely apply here, but more likely as Windows OS versions.
The text was updated successfully, but these errors were encountered: