Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Directory standard #3681

Open
eed3si9n opened this Issue Oct 27, 2017 · 6 comments

Comments

Projects
None yet
4 participants
@eed3si9n
Copy link
Member

eed3si9n commented Oct 27, 2017

steps

Run sbt.

problem

We use ~/.sbt etc.

expectation

Adhere to directory standards?

@liff

This comment has been minimized.

Copy link

liff commented Jan 31, 2018

Would it be possible to use directories like coursier does?

@dwijnand

This comment has been minimized.

Copy link
Member

dwijnand commented Jan 31, 2018

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

This comment has been minimized.

Copy link
Contributor

soc commented Apr 11, 2018

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

@dwijnand

This comment has been minimized.

Copy link
Member

dwijnand commented Apr 11, 2018

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

This comment has been minimized.

Copy link
Contributor

soc commented Apr 11, 2018

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

@ayekat ayekat referenced this issue Aug 2, 2018

Open

Get rid of remaining wrappers #23

5 of 14 tasks complete
@liff

This comment has been minimized.

Copy link

liff commented Oct 29, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.