sbt
Directory standard
steps
Run sbt.
problem
We use ~/.sbt etc.
expectation
Adhere to directory standards?
Yes - with two concerns:
- how do this change impact sbt, its launcher (sbt/launcher), its ecosystem of plugins, and plugin cross-building from the current usage of
~/.sbt, and how do we provide a graceful migration? - what's the stability of
directoriesbinary API?
@dwijnand Let me know if I can provide any information that helps sorting this out.
my first concern is more specific to sbt's current use of directories, and I haven't given it much thought.
the other one is partially directories-specific (I see the current version of directories is "10"), but it's actually generic to libraries on the jvm: selecting a library requires everything else to be compatible with that library's binary API. in sbt's case it means if we start using directories 10 then for the rest of sbt 1 all plugins will have to use directories 10 (or a version for which the API they depend on is compatible with directories 10).
@dwijnand Hi Dale!
Regarding directories: It is built on Java 6, doesn't have any dependencies and consists of 4 files (you can probably get rid of two of them). I only publish major versions, so that no person depending on it will ever get a different version from what they originally specified in their build config, without explicitly changing it himself/herself.
I would suggest shading (parts of) this library for SBT's purposes to avoid any kind of classpath or compatibility concerns. The API itself is likely to be very stable now, as I have already considered and either gone through or rejected every major redesign I (and other people) can think of. Nevertheless, you can pick a version and just stick with it.
Regarding .sbt:
- Move global config and plugins to
.config/sbt(XDG_CONFIG_HOME). - Move
.sbt/bootto.cache/sbt/boot(XDG_CACHE_HOME). - Compiled configuration should go into an appropriately named sub-directory in
.cache/sbt(XDG_CACHE_HOME). - Socket files and locks need to go to
XDG_RUNTIME_DIR. - (Optional, on Linux) Add the launcher to
.local/bin(XDG_BIN_HOME). - Introduce
SBT_CACHE_HOME,SBT_CONFIG_HOME, ... as a more principled replacement ofSBT_HOME.
Other platforms work the same, if you use directories it should work as intended out of the box. Migration can be handled in one of the ways other projects have done before, not many surprises here.
Regarding SBT's use of directories in projects: When I was still using Scala, one of the really annoying things (in addition to SBT dumping things into my $HOME dir), was that it mixed configuration and compiled artifacts all over the place.
Not being able to copy and paste build.sbt and project/ to a new directory is annoying, and unnecessarily so. Very often I just wanted to copy an existing project directory when starting a new project with similar configuration, and it took seconds for the filesystem to finish because of all the compiled artifacts dumped into project, which had to be deleted anyway.
So if you decide to clean up SBT's usage of directories, I would suggest sorting this out in the same breath – have one directory for compiled artifacts, e. g. target/project and one directory for build configuration, e. g. project, but please don't mix them.
After a version with launcher with #3598 fix is released this can be approximated with something like this set of options in either SBT_OPTS, _JAVA_OPTIONS, command line or whatever method one likes. Compiled configuration will still be under $XDG_CONFIG_HOME, though.
-Dsbt.ivy.home=$XDG_CACHE_HOME/ivy
-Dsbt.boot.directory=$XDG_CACHE_HOME/sbt/boot
-Dsbt.preloaded=$XDG_CACHE_HOME/sbt/preloaded
-Dsbt.global.base=$XDG_CACHE_HOME/sbt
-Dsbt.global.staging=$XDG_CACHE_HOME/sbt/staging
-Dsbt.global.zinc=$XDG_CACHE_HOME/sbt/zinc
-Dsbt.dependency.base=$XDG_CACHE_HOME/sbt/dependency
-Dsbt.repository.config=$XDG_CONFIG_HOME/sbt/repositories
-Dsbt.global.settings=$XDG_CONFIG_HOME/sbt/global
-Dsbt.global.plugins=$XDG_CONFIG_HOME/sbt/plugins
Add maven.repo.local, ivy.settings.dir, ivy.home and ivy.cache.dir to the mix if you like.
Taken from https://github.com/sbt/sbt/issues/6914
I kind of agree. Here's the issue I created in 2017 - https://github.com/sbt/sbt/issues/3681 Likely we can't do much in sbt 1.x, but we can hope for sbt 2.x?
Is this a possibility for 2.x? Meaning if someone wanted to contribute and work on this, is it a direction that sbt would be ok with?
@SethTisue @ckipp01 Thanks Seth, and yea, probably this would be a good area of contribution.
@eed3si9n, are there any updates on that ISSUE? It's quite annoying, especially if you're trying to adhere to XDG standards; sbt ends up cluttering the home directory.
Besides the fact that I nominated this issue to sbt 2.0 ideas post, there's been no material update on this front.