Migration from BaGet

[lg2de]

Is there anything to do to migrate from BaGet to BaGetter?
I'm currently using the latest release there, v0.4.0-preview2, with SqLite database.

[Regenhardt]

There is currently nothing you need to do aside from switching the docker image. There are however some new settings that you could add to you environment that configure new features like the stats page and health check endpoint.

You can check the default BaGetter appsettings.json in the repository. Everything not set in your environment will be used from there.

If you host without the docker image, you should also be able to just switch out the application and use your existing appsettings file or environment configuration.

The recommended way is using the docker image for the application with environment variables for configuration.
Since the last release you can also use semantic versioning to use an image like bagetter/bagetter:1, which always pulls the newest minor release of major version 1, automatically receiving features and patches without breaking/major changes.

Let me know how it went or if you need any assistance.

[Regenhardt]

This is a bug. The icon is only requested, if the package was previously uploaded including an icon, in which case the icon should have been saved alongside the package. Each package has a property HasEmbeddedIcon indicating whether or not it has an icon, so if the package is uploaded without icon (or in a version before icons were supported, so before 2020), that property would be false and the icon would not be requested at all.

From a quick look, this case should never happen. unfortunately I don't have time to dig deeper currently, but if nobody else figures it out I will look into it after i Finished my bachleor's thesis.
If I can't figure out how to fix this so that BaGetter automatically corrects this inconsistency without significant performance impact, I willadd an option to validate the database that goes through the actual files and make sure the database correctly reflects what is actually there.

As a quick fix, you could delete and push the package again. To enable full deletion, you'll have to set PackageDeletionBehavior´ to HardDelete, as the default value is Unlist` which doesn't actually delete the package.
Note that deleting the package might throw an error about the icon not existing too, but the package should still be deleted in that case.

[Regenhardt]

@lg2de your reply just vanished when I sent mine, did I somehow get it deleted accidentally?!

[lg2de]

I deleted my message because I found out that I put the files in the wrong location, one level of packages was missing.
So, the file was really not at the expected position.

Anyway, the software should act graceful if the icon is not present, isn't it?
If you agree I can try to provide a fix to handle such error message more graceful.

[Regenhardt]

Like I said, this is a case that should never happen, as this is checked when uploading the package. Migration is a specific use case, and if someone manually modifies the internal state of the package directory or database, inconsistencies are to be expected.

I'd like to avoid adding unneccesary file checks or try/catches that will be executed on every load of a package, just to handle an extremely specific case.
I'm open to solutions that don't introduce things that are called all the time though, like a startup command or button on the UI that checks for inconsistencies when requested. If there is a promising fallback process for these kind of errors, I'd much prefer it to be on the Web UI level, as downloading from there won't happen as often as a package being pulled via NuGet.