#compat mode feedback

1 messages · Page 1 of 1 (latest)

pliant grove
#

What's the exact situation you're running into it? Just to double check it's expected

heavy forge
#

Two distinct situations:

  1. I'm developing a module targeting 0.11.9, but while debugging it I want to take advantage of the new Terminal. For that to kick in, I have to manually run dev dagger develop (dev is my dev wrapper). Initially I tried removing the engineVersion field manually, but that actually defaults to latest stable

  2. I'm working on upgrading a module to the latest engine version. That involves switching back and forth between engine versions as I develop, to understand what version of my code works on which version - this gives me the status of my upgrading task. Again this requires manually dagger develop / dev dagger develop which has other side effects and is generally a distraction

#

I will add:

  1. Sometimes I'm debugging something and I'm not sure what's going on. Maybe compat mode is kicking in, maybe not - it's an extra variable to juggle. If I had a flag that gave me the confidence that I know 100% which version of the schema is served, either directly by passing the version I want, or indirectly by setting compat mode on/off, that would help me rule out that dimension of my problem
pliant grove
#

For 1., that makes total sense but seems highly specific to this exact moment in time, so I'm unsure if it by itself calls for adding knobs.

2+3 do seem like annoyances though. Some way of disabling the compat mode would do it

heavy forge
#

Also related, it would be very useful to get some sort of info message when compat mode is enabled

pliant grove
#

(there was originally a flag to specify version on dagger develop when I reviewed it but it got removed before merge, seeing if there's context on why)

#

That's obviously different than a flag to disable entirely though

#

I think there's probably too much bikeshedding required to add a flag for disabling this before the release tomorrow, so just an issue would be good for now imo.

But printing info messages might be relatively quick, I'll check if that's doable

heavy forge
#

oh yeah it's not urgent at all (or rather I don't have an opinion on how urgent it is)

#

just dumping feedback as I go

pliant grove
#

Hm even printing when compat mode is enabled raises some questions:

  1. Should it be for just the module you are directly dagger call'ing or that plus all the transitive deps loaded
  2. Should it be printed whenever the module has an engine version lower than the current one, or only when the module actually makes a call that triggers emulation of an older API (in which case it should probably only print once per-module rather than every time that happens)
small epoch
#

We could definitely bikeshed bring back the --engine-version flag - but I'd rather not have the a flag for call to disable the compat, I'd like to keep it tied to init/develop, so it keeps the engineVersion in dagger.json in sync.

#

We wouldn't want users to disable the compat in their CI (for example) if there was a call flag

small epoch
# pliant grove Hm even printing when compat mode is enabled raises some questions: 1. Should it...
  1. It definitely shouldn't be printed for transitive deps imo, that feels like it could be potentially noisy - and you might not be able to anything about it if it's not your code.
  2. I think whenever the engine version is lower - the alternative is reasonably annoying to implement imo, and also doesn't account for introspection results being different (which affects codegen, so like Void removal)
#

Also fyi to @charred drum, we discussed this previously

heavy forge
#

I think a nice readable span in the TUI might be enough?

small epoch
#

I'm pretty pro restoring the engine-version flag - we already had our first user @heavy forge ask for it almost exactly, so I think that's good reasoning for having it

heavy forge
#

Or perhaps add the schema version used, as extra detail on an existing span? Preferably a visible one

small epoch
heavy forge
#

Also another option is a bool flag --compat / --no-compat

small epoch
#

Hm 🤔 I'd rather have a flag to specify the schema that the module should be served/codegened (which is the same as setting the engineVersion field in dagger.json)

heavy forge
#

Yeah I don't have an opinion on which would be more useful in practice

small epoch
#

I don't think disabling it is quite right (since that's just equivalent to the default right? Using latest)

heavy forge
small epoch
#

But dagger develop will update to the latest - there's not really of way of "disabling" compat mode internally, it's like a fundamental change to the routing (where requests are also routed by the target version)

#

Potentially, --no-compat is just equal to dagger develop, while --compat=version pins engineVersion to that target

heavy forge
small epoch
#

Instead of --engine-version, we could have --compat

#

Hm I don't think we should allow disabling it for dependencies

heavy forge
#

there's also the case where I'm running a remote module (so dagger develop is not an option at all)

small epoch
small epoch
#

It'll likely just break if you disable it

heavy forge
#

I'm not necessarily expecting it to work. I just want to know what happens, to eliminate a variable in understanding "what the hell is going on" ™️

small epoch
#

The logic of putting this all in dagger develop is that it kicks in when you start to develop your module, calling a module should just work

heavy forge
#

Granted I haven't been using this for more than a day. So maybe we just wait for more usage experience, before adding a flag?

heavy forge
#

It spells out specifically why using dagger develop is a PITA

small epoch
#

Mm I think 2 is the case I'm most interested in

heavy forge
#

OK but to be clear I actually experienced both, so selfishly I'm interested in both 😛

#

Erik made the point that the first might be super specific to this point in time

small epoch
#

Mm I agree with that I think

#

So do we have a takeaway? Are we going to change anything before releasing?

#

Or get feedback, and bikeshed before v0.12.1?

heavy forge
small epoch
#

Out of curiosity - is this experience worse or better than previous breaking changes we made in modules? Back before ga of modules

heavy forge
#

By the way a related problem: when I do get errors in my dependency (compat-related, but maybe not relevant), the actual 'go build' error doesn't show in the output. Just a cryptic message. dagger call -i saved the day, I had to manually run go build /runtime and there was the error

heavy forge
#

I think the most painful parts in the overall experience (navigating compat-related issues) were:

  1. Cryptic error messages that did't show the actual Go errors. Without call -i I never would have know even where to start. Which felt unusual, maybe related to errors in dependencies? This may not be related to compat mode at all.

  2. The lack of idempotency. The same dagger call or dagger develop with the same dagger version may yield different results depending on what ran before (because of modified dagger.json and compat mode)

small epoch
#

The primary thing happening here is that we aren't doing version comparison on dev versions

#

But the last version compat pr in flight should fix that

#

Ideally we won't break dependencies in this way then

#

I think that would go a long way to sorting that issue out

small epoch
heavy forge
#

By the way this is easy to reproduce, I was looking at our own pipelines. You removed much of the go aliases, but some of them are still there. If you run them in a dev engine with compat mode disabled, the module won't load. And, the errors won't be visible

small epoch
#

Bleh I'll have a look at the error surfacing, that one sounds like a tui issue

heavy forge
#

compat mode feedback