| 17 Dec 2024 |
6pak | and we have the privilege of dropping ancient dotnet sdk versions, so we can just assume it's there | 22:41:11 |
GGG | In reply to @corngood:corngood.com
GGG, 6pak I am interested in the things you were discussing earlier. I'm not sure where to go with it exactly.
Runtime-specific nuget dependencies has been on my mind for a bit, but how do we get there? One way would be to clear $NUGET_PACKAGES between restoring each platform. And then you wouldn't want to bloat the deps file, so you'd also need to group them by runtime somehow.
... maybe we should make an issue to discuss that specifically, if one doesn't already exist.
I think you could just restore to separate folders and combine the results into one JSON file | 22:42:04 |
Whovian9369 | So I think I've hit a bit of a wall with trying to build my lts output... I may just say that it's "Deprecated" and call it a day unfortunately.
$ ./result/bin/aaru --version
Unhandled exception. System.TypeInitializationException: The type initializer for 'Microsoft.EntityFrameworkCore.Query.Internal.NavigationExpandingExpressionVisitor' threw an exception.
---> System.TypeInitializationException: The type initializer for 'Microsoft.EntityFrameworkCore.Query.QueryableMethods' threw an exception.
---> System.InvalidOperationException: Sequence contains more than one matching element
at System.Linq.ThrowHelper.ThrowMoreThanOneMatchException()
at System.Linq.Enumerable.TryGetSingle[TSource](IEnumerable`1 source, Func`2 predicate, Boolean& found)
at System.Linq.Enumerable.Single[TSource](IEnumerable`1 source, Func`2 predicate)
at Microsoft.EntityFrameworkCore.Query.QueryableMethods..cctor()
--- End of inner exception stack trace ---
at Microsoft.EntityFrameworkCore.Query.QueryableMethods.get_FirstWithPredicate()
at Microsoft.EntityFrameworkCore.Query.Internal.NavigationExpandingExpressionVisitor..cctor()
--- End of inner exception stack trace ---
at Microsoft.EntityFrameworkCore.Query.Internal.NavigationExpandingExpressionVisitor.Expand(Expression query)
at Microsoft.EntityFrameworkCore.Query.QueryTranslationPreprocessor.Process(Expression query)
at Microsoft.EntityFrameworkCore.Query.QueryCompilationContext.CreateQueryExecutor[TResult](Expression query)
at Microsoft.EntityFrameworkCore.Storage.Database.CompileQuery[TResult](Expression query, Boolean async)
at Microsoft.EntityFrameworkCore.Query.Internal.QueryCompiler.CompileQueryCore[TResult](IDatabase database, Expression query, IModel model, Boolean async)
at Microsoft.EntityFrameworkCore.Query.Internal.QueryCompiler.<>c__DisplayClass9_0`1.<Execute>b__0()
at Microsoft.EntityFrameworkCore.Query.Internal.CompiledQueryCache.GetOrAddQueryCore[TFunc](Object cacheKey, Func`1 compiler)
at Microsoft.EntityFrameworkCore.Query.Internal.CompiledQueryCache.GetOrAddQuery[TResult](Object cacheKey, Func`1 compiler)
at Microsoft.EntityFrameworkCore.Query.Internal.QueryCompiler.Execute[TResult](Expression query)
at Microsoft.EntityFrameworkCore.Query.Internal.EntityQueryProvider.Execute[TResult](Expression expression)
at Microsoft.EntityFrameworkCore.Query.Internal.EntityQueryable`1.GetEnumerator()
at Microsoft.EntityFrameworkCore.Internal.InternalDbSet`1.System.Collections.Generic.IEnumerable<TEntity>.GetEnumerator()
at System.Linq.Lookup`2.Create(IEnumerable`1 source, Func`2 keySelector, IEqualityComparer`1 comparer)
at System.Linq.GroupedEnumerable`2.GetEnumerator()
at System.Linq.Enumerable.WhereEnumerableIterator`1.MoveNext()
at System.Linq.Enumerable.DistinctIterator`1.MoveNext()
at System.Linq.Enumerable.SelectEnumerableIterator`2.MoveNext()
at Aaru.MainClass.Main(String[] args)
[1] 96898 abort ./result/bin/aaru --version
| 22:42:07 |
GGG | Having a key to specify which platforms you download that package for and then we filter it based on targetPlatform | 22:42:26 |
GGG | In reply to @6pak:matrix.org
GenerateRestoreGraphFile looked like it had everything we need Does it have the hashes for the packages in a format we can consume for the lockfile as well? Never heard of that | 22:42:52 |
6pak |
Never heard of that
I don't think it's documented, but nothing in msbuild land ever is ;p
| 22:43:22 |
GGG | Yeah, fair enough | 22:43:35 |
GGG | Nixpkgs has been the only reason I've ever looked into these build specific .net internals | 22:43:54 |
6pak | it doesn't have hashes annoyingly, even though it could | 22:43:56 |
6pak | we can always grab it from the nuget server though | 22:44:20 |
Corngood | That would be great, but there are a lot of annoying edge cases to test. | 22:45:35 |
6pak | the big exception are the nuget msbuild sdks which bypass the regular resolving | 22:47:06 |
GGG | there are also some packages which download packages outside of the restore target iirc | 22:47:39 |
Corngood | Sorry if I missed the context above, but is the problem just that it's on an EOL SDK? I personally would just allow the insecure dependency and continue to use it as is. | 22:47:40 |
GGG | or that don't use PackageReference and instead do something else | 22:48:10 |
GGG | we'd also need to guarantee it works with paket and et. all | 22:48:22 |
Corngood | yeah, tools and paket are the ones that come to mind. also some explicit downloads in msbuild, etc | 22:48:25 |
6pak | and imo it's fair to not handle it in the generic msbuild tooling | 22:48:24 |
Whovian9369 | That context sums it up well -- I don't really like the idea of using the insecure allowance but it may just be what I end up doing. Thanks for the thoughts! | 22:48:40 |
Corngood | That's understandable. Has the upstream project considered this? Providing an LTS build that's not on a supported platform seems odd. | 22:49:38 |
GGG | upstream seems abandoned from what I saw | 22:49:54 |
GGG | last release 2 years ago | 22:49:55 |
GGG | they have some commits but no releases in the interim | 22:50:36 |
GGG | there's a commit updating to .NET 9 rc2 but idk how stable that is | 22:50:45 |
Whovian9369 | Pre-Release was ~1yr ago | 22:51:02 |
GGG | both releases are from 2022, which is 2 years ago | 22:51:31 |
Whovian9369 | I misread the year, apologies. | 22:51:42 |
Corngood | I actually think dotnet 6 is so widely use that I'm not worried about it being EOL. There are tons of things that are less likely to get security fixes that aren't marked insecure in nixpkgs. | 22:51:47 |
GGG | you could risk building from the latest commit from the main branch | 22:51:52 |
Corngood | * I actually think dotnet 6 is so widely used that I'm not worried about it being EOL. There are tons of things that are less likely to get security fixes that aren't marked insecure in nixpkgs. | 22:52:09 |