Replies: 15 comments 9 replies
-
|
This seems like a good idea to me |
Beta Was this translation helpful? Give feedback.
-
|
We might also consider the following addition settings:
|
Beta Was this translation helpful? Give feedback.
-
|
+1 for |
Beta Was this translation helpful? Give feedback.
-
|
Why can't these things be controlled via build.sc? If you can't do it with normal syntax, add a special header. (Or use the variant you showed above instead of JSON.) |
Beta Was this translation helpful? Give feedback.
-
|
It could, but the effort to parse it somehow from the |
Beta Was this translation helpful? Give feedback.
-
|
That isn't hard if you make the start and stop lines really easy to match. And whatever parses the build.sc can throw an error if they're malformed (if it will even run at all). See several solutions at https://stackoverflow.com/questions/4857424/extract-lines-between-2-tokens-in-a-text-file-using-bash |
Beta Was this translation helpful? Give feedback.
-
|
I found out the we currently have |
Beta Was this translation helpful? Give feedback.
-
|
Seems like a good idea. One detail that occurs to me is that it might be awkward to have mill server options configurable at the project level. We could a) have those settings only available at the user level or b) restart the server every time the project changes (this does happen already for mill version changes I think). |
Beta Was this translation helpful? Give feedback.
-
|
Experience has shown, that you always need some kind of project-specific environment settings for your tool chain. Each project has different needs, e.g. memory requirements. The JVM defaults highly depend on the user environment like OS, count of CPU cores, RAM, and so on. Project-specific version-controlled settings ensure a reproducible setup for team members, CI systems and your future self. The mill server is the component which holds the various tools in caches, so it's the mill server runtime settings which determine the available memory for your compiler. |
Beta Was this translation helpful? Give feedback.
-
|
There could potentially be 3 categories (maybe not all populated): user-level-only settings, project-level-only settings, and settings that can be configured at both levels, project-level taking precedence. Some examples from this thread that would make the most sense to be user-level: proxy settings, colors Jobs is actually interesting, because you might want to have one setting locally for a project and a different one in CI. For example CI often has far fewer vCPUs and less RAM so it's more efficient and safer to have fewer threads. (More efficient because less context switching and safer because the fewer things you do at a time the less memory you need at a time. For example running scalajs on a few modules at a time has caused me OOMs on CI with too much currency, at least with SBT.) But I guess that's what the command line flag is for. 😉 |
Beta Was this translation helpful? Give feedback.
-
|
Additional to-be configurable properties:
|
Beta Was this translation helpful? Give feedback.
-
|
This whole config file idea requires us the refactor settings handling in Mill. Currently, most settings only have a configuration point in the CLI parser config. After we implemented this idea, we may have various levels of config files. This gives us the change to also support environment variables for some settings. Also, the CLI parser needs to be aware of variable defaults or of the fact whether an options was set or not. We may end up with the following configuration priority list:
|
Beta Was this translation helpful? Give feedback.
-
|
That sounds good, and standard (e.g. git has the same priority list)
On Fri Apr 1, 2022, 11:09 AM GMT, Tobias Roeser ***@***.***> wrote:
This whole config file idea requires us the refactor settings handling in
Mill. Currently, most settings only have a configuration point in the CLI
parser config. After we implemented this idea, we may have various levels
of config files. This gives us the change to also support environment
variables for some settings. Also, the CLI parser needs to be aware of
variable defaults or of the fact whether an options was set or not.
We may end up with the following configuration priority list:
- (system config - e.g. /etc/mill.conf)
- user config - $XDG_CONFIG_DIR/mill/mill.conf or $HOME/.mill.conf
- project config ./.mill.conf
- Environment variables
- Mill CLI options
—
Reply to this email directly, view it on GitHub
<#1226 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAYAUGV7XIWPZP45MX5WPTVC3KOFANCNFSM5MLHFVNA>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
If there was some sort of native launcher for mill (let's call it I am playing around with scala native and seeing if I can make a serviceable |
Beta Was this translation helpful? Give feedback.
-
|
IMHO, as long as the structure of our configuration can be kept simple, we should also keep the file format simple. If you have a good case for some more complex structure, please present it here, so we can reevaluate. |
Beta Was this translation helpful? Give feedback.
-
|
Well I was thinking we could use |
Beta Was this translation helpful? Give feedback.
-
|
I think the config example from the OP can be parsed with typesafe config library. |
Beta Was this translation helpful? Give feedback.
-
While thinking about a solution to I came across the using directive, which is used by Scala-cli and available as a stand-alone Java library (https://github.com/VirtusLab/using_directives), and which could be a lightweight replacement for Ammonite magic imports ( //> using dep "some.thirdparty::dependency::0.1.0"
//> using file "ci/some-script.sc"
//> using mill.version 0.10.5 |
Beta Was this translation helpful? Give feedback.
-
|
These are all already possible via the default By default, it uses the scala-cli config file. That config file supports many of the options suggested in this thread:
It also has key value parsers and secrets value parsers built-in, and is already included in mill's dependencies.
To maintain backward compatibility, I suggest adding an I've already been working on using this config functionality that is already built-in for managing our mill builds at work. I'd love to contribute this. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for this input.
Do you have any pointers? An open issue, maybe? |
Beta Was this translation helpful? Give feedback.
-
|
I'm in the middle of making a PR to coursier. I've already tested the change to ensure it is loading the config properly and it is working: modified modules/coursier/shared/src/main/scala/coursier/Resolve.scala
@@ -61,13 +61,7 @@ import scala.language.higherKinds
def finalRepositories: F[Seq[Repository]] = {
val repositories0 =
if (preferConfFileDefaultRepositories) {
- val defaultFromConfOpt = confFiles
- .iterator
- .flatMap(Resolve.confFileRepositories(_).iterator)
- .take(1)
- .toList
- .headOption
- defaultFromConfOpt.getOrElse(repositories)
+ confFiles.flatMap(Resolve.confFileRepositories(_).getOrElse(repositories)).toList
}
else
repositoriesI still need to apply the authentication to the imported repositories. This is binary-backwards-compatible, and source-compatible so should result in a patch version in coursier, and then we can simply upgrade mill's dependencies. For the additional config options we are talking about here, we can use the same This would be binary-backwards-compatible, as we aren't changing any existing interfaces, just adding new ones and using them in the appropriate places. That means a minor version bump for mill, which means old mill extensions will work just fine with the changes. When I'm done getting repos to load appropriately, I'll check that the proxy settings in coursier propagate to mill appropriately, and if not, figure out why and fix them in a similar manner to the config above, then I'll start a draft PR for this RFC using the config, resolve, and coursier paths + possible mill paths to get things rolling here. Alternatively, while I'm handling coursier repo config, someone else could handle the draft pr for using coursier paths to get this rolling, and I could come jump over and help after all that is done. I also want to port sbt-github-actions to mill for my new company, which would probably take about a week or so. Work can always intercede. I'll let you know here when the pr is up over on the coursier repo. I'll also need to make an issue repository so that I can report the issue and attach it to the pr. I'm trying to finish all this up today if possible. |
Beta Was this translation helpful? Give feedback.
-
|
An update -- looks like Mill uses the default |
Beta Was this translation helpful? Give feedback.
-
|
An update; So the default config does work in coursier! Became clear once I wrote the tests. It also gets pulled in via mill So now I believe the thing to do is to attach the credentials to the resolved repositories in Ok. so credentials and default repositories actually do work from the coursier cli! So my little change wasn't needed. However, `mill` resolves things slightly differently than coursier does.
coursier doesn't require me to define the authentication on the repositories it parses when it resolves dependencies from an authenticated repository. However, `mill` requires the authentication on the repositories themselves. I'm not sure why.
However, overriding the repositoryTask in a build to look like this:
```scala
import scala.concurrent.ExecutionContext.Implicits.global
val resolvedCredentials = coursier.cache.CacheDefaults.credentials.flatMap{_.get()}
val repos = Await.result(
Resolve().finalRepositories.map{_.map{
case x:IvyRepository =>
x.withAuthentication(
resolvedCredentials.find{ c =>
c.matches(x.pattern.string, c.usernameOpt.getOrElse(""))
}.map(_.authentication))
case x:MavenRepository =>
x.withAuthentication(
resolvedCredentials.find{ c =>
c.matches(x.root, c.usernameOpt.getOrElse(""))
}.map(_.authentication))
}}.future(),
Duration.Inf
)
reposThis would then use the coursier credentials properties file/environment variable/the default scala config file for any credential definition, use the coursier repositories environment variable/the default scala config file to define the values, and to add proxy we can change the above to: val resolve = Resolve.proxySetup()
...So I'll code that up and attach this discussion to the PR. |
Beta Was this translation helpful? Give feedback.
-
|
PR here: #2954 |
Beta Was this translation helpful? Give feedback.
-
Some settings are relevant for mill but can not be controlled via the
build.sc. Thus these should be placed into a config file.I think we should have only one config file which holds all various settings, that are needed to control mills behavior. In contrast to having multiple files which would clutter the directories. As such a single config file need to serve multiple entry points (e.g. the mill executable (JVM), the various start scripts (shell script), metals, IDEs) we should choose a very simple file format, which does not require any sophisticated parsing. I think some property file style without any logic should serve that purpose very well. We should also migrate and deprecate other supported config files like
.mill-versionafter that.These config files should be project specific as well as user specific, so we need to look for it in the project directory (highest priority) as well as in the user config directory (fallback).
The following settings are suspected to be configurable:
** JVM client settings (memory, stack, ...) for mill client
** JVM server settings (memory, stack, ...) for mill server
.mill-version)We need a good name for it, my candidates are:
.millrc- this is very Unix/Linux style, I'm used to it but don't know if some users expect some specific format.mill.conf- this is probably the clearest choice.mill.properties- this implies JVM properties files in ISO 8859-1 format, where I would prefer UTF-8 contentExample:
What do you think?
Beta Was this translation helpful? Give feedback.
All reactions