Directory standard

[eed3si9n]

steps

Run sbt.

problem

We use ~/.sbt etc.

expectation

Adhere to directory standards?

• File System Hierarchy Standard
• XDG Base Directory Specification

[liff]

Would it be possible to use directories like coursier does?

[dwijnand]

Yes - with two concerns:

1. 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?
2. what's the stability of directories binary API?

[soc]

@dwijnand Let me know if I can provide any information that helps sorting this out.

[dwijnand]

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).

[soc]

@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/boot to .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 of SBT_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.

[liff]

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.

[ckipp01]

Taken from #6914

I kind of agree. Here's the issue I created in 2017 - #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]

@eed3si9n (this seems like something you might have meant to reply to?)

[eed3si9n]

@SethTisue @ckipp01 Thanks Seth, and yea, probably this would be a good area of contribution.

[untainsYD]

@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.

[eed3si9n]

Besides the fact that I nominated this issue to sbt 2.0 ideas post, there's been no material update on this front.