improvements to besom-cfg #525
Conversation
lbialy
force-pushed
the
improve-besom-cfg
branch
3 times, most recently
from
a477cc1
to
e1c1563
Compare
lbialy
force-pushed
the
improve-besom-cfg
branch
from
e1c1563
to
ea877a8
Compare
| # Compiles besom-cfg k8s module | ||
| compile-cfg-k8s: publish-local-cfg-lib | ||
| compile-cfg-k8s: publish-local-cfg-lib publish-local-cfg-containers | ||
| just cli packages local kubernetes:4.17.1 |
There was a problem hiding this comment.
Is it intentional to have this version fixed here? What about publishing this module to maven? Are we going to always release besom-kubernetes for the latest k8s version and for 4.17.1? Otherwise this module will be unusable when downloaded from maven central, right?
There was a problem hiding this comment.
version is indeed fixed here and in project.scala for cfg-k8s, does it matter though? macro-stuff is going away, codegen is going to generate classes for the user without depending explicitly on besom-kubernetes.
besom-cfg/containers/.scalafmt.conf
Outdated
There was a problem hiding this comment.
Is this file actually used? It looks that our CI uses the .scalafmt.conf file from the project's root to verify formatting throughout the project
There was a problem hiding this comment.
I do open separate folders as projects in vscode since out scala-compose thing died ;_;
| @@ -3,6 +3,11 @@ package besom.cfg | |||
| import scala.quoted.* | |||
| import besom.json.* | |||
| import besom.cfg.internal.* | |||
| import besom.util.Validated | |||
| import scala.util.control.NoStackTrace | |||
| import org.checkerframework.checker.units.qual.A | |||
There was a problem hiding this comment.
I believe this line is still to be removed
There was a problem hiding this comment.
what the hell, I did kill it
| import scala.util.control.NoStackTrace | ||
| import org.checkerframework.checker.units.qual.A | ||
|
|
||
| final val Version = "0.4.0-SNAPSHOT" |
There was a problem hiding this comment.
Yet another place to remember about when bumping versions 😞
How about using scala-cli's BuildInfo to keep this up to date with what we have in the module's build definition?
There was a problem hiding this comment.
yeah but no, we're moving away from macros, right?
| end Configured | ||
|
|
||
| def resolveConfiguration[A](using c: Configured[A]): A = | ||
| c.newInstanceFromEnv() | ||
| def resolveConfiguration[A, INPUT: Default](using c: Configured[A, INPUT]): A = |
There was a problem hiding this comment.
Is this supposed to be proper API for users?
Should they then call something like resolveConfiguration[Foo, Map[String, String]]?
Are we sure this is going to work well when we mix type inference and implicit resolution with overloading?
There was a problem hiding this comment.
this is a good question and I think this was WIP but since we're killing macros-based approach we can ignore this and figure that out later, no?
No description provided.