| 10 Jan 2025 |
 6pak | because link would mean you still have everything in closure, copy means you have the same thing twice in store/cache | 17:04:58 |
 Corngood | right, I thought it would be better to favour build closure size for dependent projects | 17:05:49 |
| 6pak |
You do need to define the list of packages at eval time, which is annoying.
can't you do it at fetch-deps stage?
| 17:05:55 |
| Corngood | $ cat result/share/nuget/source/avalonia/11.0.11/avalonia.nuspec
<?xml version="1.0" encoding="utf-8"?>
<package xmlns="http://schemas.microsoft.com/packaging/2013/05/nuspec.xsd">
<metadata>
<id>Avalonia</id>
<version>11.0.11</version>
<authors>Avalonia Team</authors>
<license type="expression">MIT</license>
<licenseUrl>https://licenses.nuget.org/MIT</licenseUrl>
<icon>Icon.png</icon>
<projectUrl>https://avaloniaui.net/</projectUrl>
<description>Avalonia is a cross-platform UI framework for .NET providing a flexible styling system and supporting a wide range of Operating Systems such as Windows, Linux, macOS and with experimental support for Android, iOS and WebAssembly.</description>
<releaseNotes>https://github.com/AvaloniaUI/Avalonia/releases</releaseNotes>
<copyright>Copyright 2013-2025 © The AvaloniaUI Project</copyright>
<tags>avalonia avaloniaui mvvm rx reactive extensions android ios mac forms wpf net netstandard net461 uwp xamarin</tags>
<repository type="git" url="https://github.com/AvaloniaUI/Avalonia/" />
<dependencies>
<group targetFramework=".NETFramework4.6.1">
<dependency id="Avalonia.Remote.Protocol" version="11.0.11" exclude="Build,Analyzers" />
<dependency id="Microsoft.Bcl.AsyncInterfaces" version="6.0.0" exclude="Build,Analyzers" />
<dependency id="System.ComponentModel.Annotations" version="4.5.0" exclude="Build,Analyzers" />
<dependency id="System.Memory" version="4.5.3" exclude="Build,Analyzers" />
<dependency id="System.Runtime.CompilerServices.Unsafe" version="4.6.0" exclude="Build,Analyzers" />
<dependency id="System.Threading.Tasks.Extensions" version="4.5.4" exclude="Build,Analyzers" />
<dependency id="System.ValueTuple" version="4.5.0" exclude="Build,Analyzers" />
<dependency id="MicroCom.Runtime" version="0.11.0" exclude="Build,Analyzers" />
</group>
<group targetFramework=".NETCoreApp2.0">
<dependency id="Avalonia.Remote.Protocol" version="11.0.11" exclude="Build,Analyzers" />
<dependency id="Microsoft.Bcl.AsyncInterfaces" version="6.0.0" exclude="Build,Analyzers" />
<dependency id="System.ComponentModel.Annotations" version="4.5.0" exclude="Build,Analyzers" />
<dependency id="System.Memory" version="4.5.3" exclude="Build,Analyzers" />
<dependency id="System.Runtime.CompilerServices.Unsafe" version="4.6.0" exclude="Build,Analyzers" />
<dependency id="System.Threading.Tasks.Extensions" version="4.5.4" exclude="Build,Analyzers" />
<dependency id="System.ValueTuple" version="4.5.0" exclude="Build,Analyzers" />
<dependency id="MicroCom.Runtime" version="0.11.0" exclude="Build,Analyzers" />
</group>
<group targetFramework="net6.0">
<dependency id="Avalonia.Remote.Protocol" version="11.0.11" exclude="Build,Analyzers" />
<dependency id="System.ComponentModel.Annotations" version="4.5.0" exclude="Build,Analyzers" />
<dependency id="MicroCom.Runtime" version="0.11.0" exclude="Build,Analyzers" />
</group>
<group targetFramework=".NETStandard2.0">
<dependency id="Avalonia.Remote.Protocol" version="11.0.11" exclude="Build,Analyzers" />
<dependency id="Microsoft.Bcl.AsyncInterfaces" version="6.0.0" exclude="Build,Analyzers" />
<dependency id="System.ComponentModel.Annotations" version="4.5.0" exclude="Build,Analyzers" />
<dependency id="System.Memory" version="4.5.3" exclude="Build,Analyzers" />
<dependency id="System.Runtime.CompilerServices.Unsafe" version="4.6.0" exclude="Build,Analyzers" />
<dependency id="System.Threading.Tasks.Extensions" version="4.5.4" exclude="Build,Analyzers" />
<dependency id="System.ValueTuple" version="4.5.0" exclude="Build,Analyzers" />
<dependency id="MicroCom.Runtime" version="0.11.0" exclude="Build,Analyzers" />
</group>
</dependencies>
</metadata>
</package>%
| 17:06:09 |
| 6pak | like the info you need is literally in nuget restore metadata | 17:06:09 |
| Corngood | then you're using packages from nuget.org or something. maybe if you had fetch-deps use the master avalonia package/? | 17:06:48 |
| Corngood | * then you're using packages from nuget.org or something. maybe if you had fetch-deps use the master avalonia package? | 17:06:50 |
| 6pak | but different outputs would solve it with no negatives right? (assuming they work how I think they do) | 17:06:50 |
| 6pak | oh you mean a list in consuming projects? | 17:07:27 |
| Corngood | it wouldn't be different from having separate derivations | 17:07:29 |
| 6pak | you would build avalonia twice | 17:07:44 |
| 6pak | * you would build avalonia once | 17:07:54 |
| Corngood | oh I see. I guess it would save storing the monolithic output, but that wouldn't be used directly by anything | 17:08:45 |
| 6pak | unless with the copy approach you would make the monolith uncacheable, which also works I guess? | 17:08:52 |
| 6pak | but it feels like the outputs thing was literally designed for this | 17:09:16 |
| Corngood | I pasted the nuspec above to show the dependencies. If they were all separate, you'd have to do buildInputs = [ avalonia avalonia-remote-protocol ], etc. | 17:09:52 |
| Corngood | Unless we teach the builder to understand those dependencies and propagate them. | 17:10:13 |
| 6pak | can't you just use propagatedBuildInputs? | 17:10:28 |
| Corngood | yeah, but you need to get the dependencies from the nuspec:
<group targetFramework="net6.0">
<dependency id="Avalonia.Remote.Protocol" version="11.0.11" exclude="Build,Analyzers" />
| 17:10:56 |
| Corngood | and they depend on target frameworks, etc | 17:11:12 |
| 6pak | you could get it at avalonia's fetch-deps stage | 17:11:28 |
| 6pak | nuget restore includes figuring out projectreferences metadata | 17:11:44 |
| Corngood | it's the output of avalonia, so I think you'd have to do it in the dependent project's fetch phase? | 17:11:59 |
| Corngood | oh wait, I see what you mean | 17:12:10 |
| Corngood | yeah, maybe fetch-deps could determine something about the output packages. but still you have dependencies that are dependent on TFM. so a dependent project on net6.0 and netstandard2.0 might have different dependencies. you could be conservative and link all of them I guess | 17:12:58 |
| 6pak | this would be bad though | 17:13:02 |
| Corngood | I didn't completely give up on it. this is just where it started to get hairy and I was trying to use the nuget sdk to figure out dependencies etc | 17:13:43 |
| 6pak | tbh listing it out manually might not be that bad | 17:14:11 |
| Corngood | yeah, maybe not. avalonia is probably about as complex as it gets | 17:14:31 |
| 6pak | yeah | 17:14:37 |
