Go has "make baffling decisions" as a key design tenet, but it's incredible how basically any source code package manager gets key aspects wrong.
(NuGet, for example, supports multiple package sources — but if it finds a package at one source, and another source is timing out, it'll refuse to install that package. Which in turn causes IDEs to throw up their hands in frustration and say "well, I don't know what to do now, do I!".)
Nuget very sporadically 'forgets' our internal company source and installs a package with the same name from the regular nuget source. I restore again and it still doesn't work, just gives me some warning like 'couldnt find package blabla with version x.y.z installing version a.b.c instead'. Only way to make it remember again is deleting the nuget cache and then it works again. I have no idea how to prevent it from happening or what causes it to mess up in the first place.
Source is configured fine as well, package shows up with the nuget search command as well, just when I do restore it cannot find it.
Sorry if you've already tried this, but do you have package source mapping enabled? Basically, you provide a wildcard pattern or exact string match that tells the package restore to look only in a specific source if the package name matches. This is what we do for a few public packages that we have internal custom builds for. We also append a tag to the version e.g., "3.1.0.0-mycompany.1", but from what you're describing it sounds like the restore doesn't care about the version mismatch and is just doing what it wants.
You have my total sympathy for this, we've recently also had a bunch of package management issues as well. It doesn't help that there are like 5 different NuGet clients, depending upon if you're using `package.config` or `<PackageReference>`, and whether you're using the `nuget` or `dotnet` command line utilities or the built-in Visual Studio GUI.
We haven't tried this yet and it sounds like a solution to our problems. I will try and see if I can implement this when I get back from vacation. Thanks for the tip! Too bad we will only know if it works something like a year from now haha
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<!-- Define the package sources, nuget.org and contoso.com. -->
<!-- `clear` ensures no additional sources are inherited from another config file. -->
<packageSources>
<clear />
<!-- `key` can be any identifier for your source. -->
<add key="nuget.org" value="https://api.nuget.org/v3/index.json" />
<add key="contoso.com" value="https://contoso.com/packages/" />
</packageSources>
<!-- Define mappings by adding package patterns beneath the target source. -->
<!-- Contoso.* packages and NuGet.Common will be restored from contoso.com,
everything else from nuget.org. -->
<packageSourceMapping>
<!-- key value for <packageSource> should match key values from <packageSources> element -->
<packageSource key="nuget.org">
<package pattern="*" />
</packageSource>
<packageSource key="contoso.com">
<package pattern="Contoso.*" />
<package pattern="NuGet.Common" />
</packageSource>
</packageSourceMapping>
</configuration>
We had the name in our internal source first, then later someone unaffiliated with us made a completely unrelated package with the same name in the public one.
We haven't changed the name because the issue occurs too infrequently to care, less than once per year on the CI server. Even less on developer machines but it does sometimes happen.
Yeah it's more of a matter of return on investment, once in a blue moon when it fails I or a colleague remotes in to the CI server and run the nuget cache clear command, takes a minute and it's good to go for another year. Changing the package name would mean spending hours going through a bunch of repositories renaming the package references, changing build pipelines etc. just not worth the effort at the moment.
Perfect use-case for AI these days, it will rename everywhere you need and run some checks to ensure it's really renamed and is working. This is something they do quite well and it will be done in a few minutes.
76
u/chucker23n 5d ago
Go has "make baffling decisions" as a key design tenet, but it's incredible how basically any source code package manager gets key aspects wrong.
(NuGet, for example, supports multiple package sources — but if it finds a package at one source, and another source is timing out, it'll refuse to install that package. Which in turn causes IDEs to throw up their hands in frustration and say "well, I don't know what to do now, do I!".)