<DasSkelett[m]>
No DRM for single player, but nothing about mod distribution. Only that they are "major priority".
VITAS[m] has joined #spacedock
<VITAS[m]>
ofcause it is
aradapilot has quit [Ping timeout: 190 seconds]
AllisTauri[m] has quit [Quit: Idle timeout reached: 10800s]
AllisTauri[m] has joined #spacedock
<AllisTauri[m]>
DasSkelett: sorry, actually couldn't follow you: where did I miss it "for `notify_ckan`"?
DasSkelett[m] has quit [Quit: Idle timeout reached: 10800s]
VITAS[m] has quit [Quit: Idle timeout reached: 10800s]
DasSkelett[m] has joined #spacedock
<DasSkelett[m]>
Uhh, RockyTV wrote that, not me
RockyTV[m] has joined #spacedock
<RockyTV[m]>
I corrected later
<AllisTauri[m]>
Sorry ~_~'
<RockyTV[m]>
DasSkelett I really hope they keep up with no drm and no mtxns
VITAS[m] has joined #spacedock
<VITAS[m]>
they will try to change stuff they think they can get away with (and they think shiould be done right this time).
<VITAS[m]>
the main reason theyre doing ksp 2 is to have their own solid base to build uppon.
<DasSkelett[m]>
I don't think they will break such a strong promise.
<VITAS[m]>
squads code is grown and is based on some tinkering project by a non game dev
<VITAS[m]>
i think they advertise what they know will calm people opposing a new ksp
<VITAS[m]>
drm, no mods,....
<VITAS[m]>
and sweeten the deal with "you wanted that MP so urgently didnt you?"
<VITAS[m]>
its not about the "if" more about the "how"
<VITAS[m]>
so no drm but how will they protect it from copies?
<VITAS[m]>
mods but how will they implement modding
<VITAS[m]>
and MP but how will they solve it
<RockyTV[m]>
DasSkelett it's take2 and private division
<RockyTV[m]>
so I wouldn't take it as a solid promise
<VITAS[m]>
i expect relativation of promises and doublespeak to cover it
<VITAS[m]>
but i expect that with all companies and even people
<VITAS[m]>
like the person filming me while putting up a "no photos" sign a week ago
<VITAS[m]>
he told me he wasnt taking photos but filming.
<AllisTauri[m]>
)))
aradapilot has joined #spacedock
<VITAS[m]>
pling
aradapilot has quit [Remote host closed the connection]
<VITAS[m]>
forum post in regards to the new game "ancestors": "Anyone else having trouble mating or just me?"<- i so urgently want to comment that :D
<AllisTauri[m]>
)))
aradapilot has joined #spacedock
<VITAS[m]>
plong
<AllisTauri[m]>
What are those?
<VITAS[m]>
?
<VITAS[m]>
what?
<AllisTauri[m]>
pling/plong/plang/pleng?
<VITAS[m]>
just commenting the frequent joins and parts of aradapilot
<AllisTauri[m]>
🤣
<aradapilot>
flakey vpn!
<VITAS[m]>
improve it then
<VITAS[m]>
or use bouncers
<AllisTauri[m]>
And I'm creating sqlalchemy schema for a work accounting for a company of some 2k employees T_T
<VITAS[m]>
speaking of witch: any idea on how to solve the config.ini problem?
<AllisTauri[m]>
what, one way merging of configs? sure)
<VITAS[m]>
aka non destructive updates of config.ini on dev sys
<AllisTauri[m]>
they may be destructive on the level of options
<AllisTauri[m]>
the only thing they shouldn't do is to change the values of the existing options
<VITAS[m]>
and how could we technicaly realize that? ims ure there are plenty of existing solutions
<VITAS[m]>
as i see it: adding keys to the file is ok (with defaults) but removing or worse altering existing ones is bad. so we need some sort of management aside from git to handle those changes much like sql migrations/versions
<AllisTauri[m]>
removing is also OK, because if the example doesn't have a key, it shouldn't be used anywhere in the code
<VITAS[m]>
it could also initaly set up a basic config.ini when freshly install and detect working values for keys (e.g. paths)
<AllisTauri[m]>
that is quite a different scope
<VITAS[m]>
yes. im just wondering iof you know such a solution we could use.
<VITAS[m]>
my primary goal ist to make contribution as easy as possible. parts are your code simplifications and cleanup, parts are existing infrastructure and services and parts are atuimation and ease of setting up dev envs
<AllisTauri[m]>
Not tested, but the idea is:
<AllisTauri[m]>
```
<AllisTauri[m]>
...(truncated)
<AllisTauri[m]>
forgot to remove obsolete sections
<VITAS[m]>
or we have somethign lieke a versioning where we have multiple "patches" to a file altering its final state and rollbacks for each patch
DasSkelett[m] has quit [Quit: Idle timeout reached: 10800s]
<VITAS[m]>
so baseconfig ->patch1->patch2->...->current config
<AllisTauri[m]>
What for?
<VITAS[m]>
so the config qould have a version key and each alteration would deal with rolling out and back their config change individualy
<VITAS[m]>
because not every change demands the same action
<AllisTauri[m]>
yea, but what for?)
<VITAS[m]>
im thinking of ways to also debug stages of changes
<AllisTauri[m]>
You don't actually roll-back a living service like this. Not in parts and pieces. VM disk snapshots, DB snapshots... not the alembic for every single filetype you use in live system.
<VITAS[m]>
i update systems and might want to roll back dev systems (either local or alpha)
<AllisTauri[m]>
So automation that just modifies the file to keep in line with the repo -- doable and simple. Anything besides, and you should look at global scale
<VITAS[m]>
but im more about making individual changes visible
<AllisTauri[m]>
might want -- did that happen? how many times?
<AllisTauri[m]>
Ok, so make a local git repo, use the script above, then commit the change.
<VITAS[m]>
im ok with what works :)
<AllisTauri[m]>
Or simply backup the old file to a directory
<AllisTauri[m]>
they're not big, updates are rare
<VITAS[m]>
my thoughtprocess was: what else do i know where keys change over the dev periot...DB...how are updates to its structure managed?...verions/patches/migrations
<AllisTauri[m]>
That's because relational databases are deviously complex and couldn't be updated like files -- schema and data are not separable
<VITAS[m]>
i agree that we should try a simpler approach first and only resort to complexer solutions if we have the need
<AllisTauri[m]>
*looked some more for a generic merging/migration tool; nothing
<AllisTauri[m]>
So I'll implement the basic backup-then-merge logic as a subcommand of the `spacedock` CLI
RockyTV[m] has quit [Quit: Idle timeout reached: 10800s]
HebaruSan[m] has joined #spacedock
<HebaruSan[m]>
Why not make a rule that code has to be robust in the face of missing config? Then treat crashes like what we just saw as bugs and fix them?
<HebaruSan[m]>
`_cfgl` could be updated to not call `literal_eval` on null values
<RockyTV>
DasSkelett, are you english?
<RockyTV>
or HebaruSan , AllisTauri[m]
DasSkelett[m] has joined #spacedock
<DasSkelett[m]>
Nope, German
<HebaruSan[m]>
American of German heritage
<RockyTV>
alright I'll pm you then
<HebaruSan[m]>
Does this mean I have to log in to IRC now?
<RockyTV>
I sent to you via matrix
<HebaruSan[m]>
I'm only on Discord
<RockyTV>
okay hang on
<HebaruSan[m]>
Why are the `_cfg` functions implemented as lamdas instead of normal `def` functions?
<RockyTV>
compact code!
aradapilot has quit [Remote host closed the connection]
aradapilot has joined #spacedock
<RockyTV>
btw HebaruSan[m] sent you a discord message
<AllisTauri[m]>
Making code robust is fine, but it'll make harder to notice when something non critical happens.
<AllisTauri[m]>
In this case no one would've noticed the absence of the links.
<AllisTauri[m]>
So we should do both: make node robust and migrate configs
<AllisTauri[m]>
Implementation of those _cfgN is bad; it's highly recommended to create normal function if you need "to save a lambda under a name", because lambda, by definition, is a nameless function
<AllisTauri[m]>
And of course this accessors should handle missing values and such gracefully
<RockyTV[m]>
looks like it does support fallback/default values
<AllisTauri[m]>
Even better: there are two independent mechanisms: fallback values and config defaults.
<AllisTauri[m]>
First is per `.get` call, second allows one to set default value that are accessible as if they were present in **all** sections
<AllisTauri[m]>
Default valueS
<HebaruSan[m]>
We only use one section though
<AllisTauri[m]>
We don't, actually, as this "section" is named differently in different configs
<AllisTauri[m]>
Defaults could be provided for all sections directly in the config
<HebaruSan[m]>
Huh?
<AllisTauri[m]>
It's named `dev` and `prod` depending on environment, is it not?
<HebaruSan[m]>
Doesn't look like it. 'dev' is hard coded in config.py
<AllisTauri[m]>
So what I'd do is:
<AllisTauri[m]>
Make config with sections per environment and with the `DEFAULT` section describing common options
<HebaruSan[m]>
But 1.) each server is only going to be one kind of environment, and 2.) that doesn't help us with config migration/changes
<AllisTauri[m]>
We could always safely update default section, as it's environment agnostic and in any case is overridden by options in other sections
<AllisTauri[m]>
Than any new options will be automatically available and overridable
<HebaruSan[m]>
This touches on a question that could probably use more clarity:Are we trying to make a generic platform that could be used by projects other than spacedock.info? Or is it just for that?
<HebaruSan[m]>
Because for example, other projects should NOT have a default value for support-channels containing our Discord link default in on upgrade
<AllisTauri[m]>
It helps: ConfigParser can update itself from several files. We could keep a config with default session in repo, then pull options from there, then update them from server's config
<HebaruSan[m]>
If we're just doing spacedock.info, then a lot of this stuff doesn't even need to be configurable
<AllisTauri[m]>
This may be handled by keeping different branches with .gitattributes that shields configs during merges
<AllisTauri[m]>
And even if you have only one production environment, keeping data and code separate is always a good thing
<AllisTauri[m]>
And config is data
<HebaruSan[m]>
I guess I don't see a need to complicate things
<HebaruSan[m]>
Agreed, and config doesn't belong in a code repo
<AllisTauri[m]>
Don't agree)
<AllisTauri[m]>
It's perfectly ok to keep strong-coupled configs in repo on dedicated branches
<HebaruSan[m]>
This is getting very far afield from the actual problem that we have 🙂
<HebaruSan[m]>
Which was that _cfg throws an exception for a value missing from config.ini
<HebaruSan[m]>
That's trivially fixable
<AllisTauri[m]>
As usual)
<AllisTauri[m]>
Yep. Adding defaults is also trivial and is a better approach than the current `.example`
<AllisTauri[m]>
And we should include `alembic.ini` in repo, as it's part of the alembic system, project specific, doesn't depend on environment
<AllisTauri[m]>
So I say, we do both. Robust accessors, cascading configs.
<HebaruSan[m]>
Again, defaulting would not have been an appropriate solution to the `support-channels` crash
<AllisTauri[m]>
Why not?
<AllisTauri[m]>
We have alpha/beta branches; we could have prod branch as well.
<AllisTauri[m]>
...(truncated)
<HebaruSan[m]>
So there are no known motivating use cases for this?
<AllisTauri[m]>
Didn't get this one
<HebaruSan[m]>
Oh, you meant why not use defaulting for `support-channels`.
<HebaruSan[m]>
As noted above, it would not make sense for other projects using the codebase to have defaulted in links to this Discord
<HebaruSan[m]>
And if you would use an empty default, we get that already with robust accessors
<AllisTauri[m]>
I suggested in my review just now to **not** imply any defaults in accessors.
<AllisTauri[m]>
And if anyone wants to use this code-base, why not start from the `master`, or fork whatever branch they need and change their defaults there?
<HebaruSan[m]>
Yeah, I don't agree with that review, will add comment in the PR
<RockyTV>
I disagree with AllisTauri[m]
<RockyTV>
you have functions that you expect to return certain types. if you return None you're asking for a special treatment when that happens
<RockyTV>
might as well as throw an exception if the value can't convert to your type
<HebaruSan[m]>
Yeah the whole point is that the calling code should not have to care whether the value is set in the ini or not
<RockyTV>
I think it's probably going to crash even after the strict type checking
<RockyTV>
nevermind
<AllisTauri[m]>
Error/exception handling is all about knowing what happens. It's easier to check for None value than to try/except things each time. But as with int and literal eval cases, that's no good default value, because your code may expect only integers greater than zero, or list instead of the "default" dict.
<HebaruSan[m]>
Such code would also have to deal with the user putting "setting=0" in the config.ini
<HebaruSan[m]>
If its solution is to throw an exception, fine
<AllisTauri[m]>
So it's not the proper type we should be returning, but a value instead of exception.
DasSkelett[m] has quit [Quit: Idle timeout reached: 10800s]
<AllisTauri[m]>
It's not the responsibility of an accessor to decide on the default value. If you want one, add the `default=` argument to them
<HebaruSan[m]>
Just did 🙂
RockyTV[m] has quit [Quit: Idle timeout reached: 10800s]
AllisTauri[m] has quit [Quit: Idle timeout reached: 10800s]
HebaruSan[m] has quit [Quit: Idle timeout reached: 10800s]