Client mods are still downloaded despite supplying `-s server` in clean instance

[TechnoSparks]

Description

I am having an issue where in a clean environment, packwiz-installer would download client-side mods despite setting argument -s server or --side server when calling the bootstrapper. I notice this when my server crash on startup due to a client-side mod Better Loading Screen

Steps to replicate

• Setup a clean new Minecraft (mc) server folder
• Add a mod to a packwiz project,
  • edit its .toml file by specifying side = "client"
• Run packwiz-installer-bootstrap in the mc server folder
• Confirm that it downloads the client-side mod in the server's mod folder

Behaviour analysis

• This only happens when running the bootstrapper in a clean environment due to the absence of packwiz.json
  • When an mc instance is already bootstrapped (packwiz.json exists), deleting the mods folder and running the bootstrapper again will not download the client-side mods
• I have not checked to see if packwiz-installer downloads server mods when the bootstrapper is supplied with -s client. I am under the assumption that it would behave the same

Possible fix

• Generate packwiz.json too in packwiz project folder?
  • Needs modification to packwiz, not packwiz-installer

Workaround for other users

• Distribute your modpack with packwiz.json in it
  • This will require you to first have a local instance that has been bootstrapped by packwiz-installer. Copy its packwiz.json to your clean instance that was meant for distribution in MultiMC

[comp500]

I can't seem to replicate this bug if I remove packwiz.json... though it doesn't seem to recognise when the side passed in the command line is different from the cached data in packwiz.json (but that would be fixed by removing packwiz.json). I'm surprised you're getting issues with no packwiz.json - I seem to get more issues with it present but out of date (i.e. when I modify the side field on a file that is already installed).

[TechnoSparks]

Oh no if you are not able to replicate it, then it could be with my setup. I'll try again in a super-duper clean environment maybe in a Linux VM. If it would be of any help, I am on Windows. Forgot to mention that in the original post.

I did however try to nail down on the exact cause by deleting 200+ of my mods (200MB) repeatedly before ultimately opening this issue. Now just after typing this, I realise that I could've been much more efficient by using a small set of mods. Could it be the size of the modpack matters?

I'll report back later when I have ample free time

EDIT: IF you are interested in attempting to replicate based on the pack.toml i made, the address would be https://raw.githubusercontent.com/TechnoSparks/Better-SMC/main/pack.toml

[TechnoSparks]

Hm 😕 I guess I may have embarrassed myself because it now doesn't happen anymore. 😅 I am unable to replicate my own reported issue. I don't understand why I have this anomaly before I opened the issue, the most probable cause would be due to my negligence because I may have not triple-check if -s server is present in my terminal

[TechnoSparks]

OK after trying to backtrack on what I did I think what I experienced ultimately is just what you described:

I seem to get more issues with it present but out of date (i.e. when I modify the side field on a file that is already installed).

Only after when i decided to delete packwiz.json that I most likely have goofed up by missing -s server. But it is strange that when I check terminal history I fail to find an incident where I missed the -s switch. I don't know but I'd like to not think about this anymore because it hurts my head!

[TechnoSparks]

Sorry about the spam! I finally realised the problem i was facing all along is at fault somewhere with packwiz-installer not acknowledging that pack.toml has changed.

This is because I was trying to replicate your aforementioned issue regarding packwiz.json being out of date. At first, I thought it was GitHub serving stale raw pack.toml, but when I visit the raw file link right after pushing a commit, GitHub served me a correct new file. This raised an eyebrow! When I run the packwiz-installer-bootstrap again, it still does not update to the one's in my repo. After a few inconsistent minutes, I retry again which resulted in packwiz-installer properly sync changes.

Does packwiz-installer (or related dependencies) caches the downloaded pack.toml until a set time?

[comp500]

Does packwiz-installer (or related dependencies) caches the downloaded pack.toml until a set time?

It doesn't... but you may have hit this bug if the only change you made to the file was the side. I'm working on rewriting the installer code to make it much more reliable and fix these issues.