Copy manual-repo.nix to baseDirectory.value

[Ma27]

This change contains the last feature I requested in #23

This patch contains a very basic implementation by just copying the manual-repo.nix if no manual-repo.nix is present already.
It can be modified after that as SBTix doesn't keep track of its changes. However we might want to evaluate a better long-term solution during the work on #27

[Ma27]

@teozkr that's odd: when running sbt scripted in the plugin/ directory (this was the command that failed the build) I get a zero exit code and everything works... (will do some investigation tomorrow)

[nightkr]

download error: Caught java.net.ConnectException: Connection timed out (Connection timed out) (Connection timed out (Connection timed out))

Seems like Travis had some connection issues, retrying the build now.

[Ma27]

@teozkr still failing. Will try to investigate in the next time :-)

[Ma27]

@teozkr I found the root cause of the issue:

[info] coursier.ResolutionException: Encountered 1 error(s) in dependency resolution:
[info]   private-org:private-name:1.2.3:
[info]     download error: Caught java.net.NoRouteToHostException: No route to host (Host unreachable) (No route to host (Host unreachable))
[info]     not found:
[info]       /home/travis/.ivy2/local/private-org/private-name/1.2.3/ivys/ivy.xml
[info]       https://repo1.maven.org/maven2/private-org/private-name/1.2.3/private-name-1.2.3.pom
[info]       /tmp/sbt_9e86889a/private-auth/global/preloaded/private-org/private-name/1.2.3/ivys/ivy.xml
[info]       /tmp/sbt_9e86889a/private-auth/global/preloaded/private-org/private-name/1.2.3/private-name-1.2.3.pom
[info] [error] (three/*:coursierResolution) coursier.ResolutionException: Encountered 1 error(s) in dependency resolution:
[info] [error]   private-org:private-name:1.2.3:
[info] [error]     download error: Caught java.net.ConnectException: Connection timed out (Connection timed out) (Connection timed out (Connection timed out))
[info] [error]     not found:
[info] [error]       /home/travis/.ivy2/local/private-org/private-name/1.2.3/ivys/ivy.xml
[info] [error]       https://repo1.maven.org/maven2/private-org/private-name/1.2.3/private-name-1.2.3.pom
[info] [error]       /tmp/sbt_9e86889a/private-auth/global/preloaded/private-org/private-name/1.2.3/ivys/ivy.xml
[info] [error]       /tmp/sbt_9e86889a/private-auth/global/preloaded/private-org/private-name/1.2.3/private-name-1.2.3.pom
[info] [error] (one/*:coursierResolution) coursier.ResolutionException: Encountered 1 error(s) in dependency resolution:
[info] [error]   private-org:private-name:1.2.3:
[info] [error]     download error: Caught java.net.NoRouteToHostException: No route to host (Host unreachable) (No route to host (Host unreachable))
[info] [error]     not found:
[info] [error]       /home/travis/.ivy2/local/private-org/private-name/1.2.3/ivys/ivy.xml
[info] [error]       https://repo1.maven.org/maven2/private-org/private-name/1.2.3/private-name-1.2.3.pom
[info] [error]       /tmp/sbt_9e86889a/private-auth/global/preloaded/private-org/private-name/1.2.3/ivys/ivy.xml
[info] [error]       /tmp/sbt_9e86889a/private-auth/global/preloaded/private-org/private-name/1.2.3/private-name-1.2.3.pom
[info] [error] Total time: 153 s, completed Aug 8, 2017 10:25:39 PM

Seems as the private-auth test breaks because this private-org:private-name artifact doesn't exist in Maven Central.
As I don't know enough about the dependency resolution internals of SBTix ATM I'd have to pass this to you @teozkr :-)

[nightkr]

Huh, yeah, that's odd. Seems like it's unable to reach Maven Central? But that makes no sense, since it's able to download everything else...

[nightkr]

Seems like it was a temporary network issue, since Travis succeeded now without any changes. Sorry about the slow response.

[Ma27]

ok, nice :-)

I'm currently on vacation, but I'll try to prepare a patch after that for #27 :-)

[Ma27]

btw @teozkr do we want to publish a release before working on getting rid of Nix as explicit dependency?

Furthermore I'd like to ask if it's okay to add sbtix to the NixOS package set as it makes usage IMO way easier (e.g. nix-shell -p sbtix --run "...") :-)

[nightkr]

btw @teozkr do we want to publish a release before working on getting rid of Nix as explicit dependency?

Yeah, probably. As long as we don't commit to any stability guarantee yet...

Furthermore I'd like to ask if it's okay to add sbtix to the NixOS package set as it makes usage IMO way easier (e.g. nix-shell -p sbtix --run "...") :-)

Yeah, originally the plan was to try to get this into Nixpkgs once I was happy about the API. That said, #27 will mean that we don't need a separate command anymore, so is it worth pestering the Nixpkgs maintainers over what will (hopefully) be deprecated in 0.3 anyway?

[Ma27]

Yeah, probably. As long as we don't commit to any stability guarantee yet...

agreed. I think think we should push a 0.x release for now and bump the minor version number when shipping new features. According to the semver guidelines these preview/dev releases can (even) contain BC breaks, so I think this implies that the code is not100% stable ATM.
After shipping more features (like #27) I'd propose to wait (maybe even one year) to gather feedback before considering a stable release.

Yeah, originally the plan was to try to get this into Nixpkgs once I was happy about the API. That said, #27 will mean that we don't need a separate command anymore, so is it worth pestering the Nixpkgs maintainers over what will (hopefully) be deprecated in 0.3 anyway?

I have to disagree with you in that case: the sbtix.nix which contains the SBTix derivations is maintained by our side, all we need is a fetchgit and a pkgs.callPackage expression to make it work in the nixpkgs. It will be available for each user and we don't have to bother the maintainers with too much derivation changes after each release becuase of internal changes (like getting rid of Nix as dependency). After new releases we simply have to bump the git tag in nixpkgs and that's it.
Furthermore I don't think that the public API will break (it's actually quite nice after the last changes we pushed), only several internals (or newly added options), so users of the NixPkgs package set don't have to fear possible breaks after a channel update.

If you're fine with it, I'd open a PR on nixpkgs in the next time :-)

[nightkr]

I have to disagree with you in that case: the sbtix.nix which contains the SBTix derivations is maintained by our side, all we need is a fetchgit and a pkgs.callPackage expression to make it work in the nixpkgs. It will be available for each user and we don't have to bother the maintainers with too much derivation changes after each release becuase of internal changes (like getting rid of Nix as dependency). After new releases we simply have to bump the git tag in nixpkgs and that's it.

Oh, you want to merge buildSbt* as well? I'm not sure what we'd get from that, considering that Sbtix-the-plugin will now keep Sbtix.nix up to date automatically, and that Sbtix.nix is not very useful without the plugin. The pain of having to keep it updated is also mostly gone now, since the plugin will do that automatically.

[Ma27]

ah I'm sorry, I meant sbtix-tool.nix.
We don't have to bother the NixPkgs maintainers with huge changes in the SBTix derviation for each release, we simply need to bump the git tag in NixPkgs.

[nightkr]

True, but #27 would mean removing sbtix-tool.nix entirely anyway, since that was just a stopgap for running "SBT + the plugin". Switching to publishing to Maven would mean that it's just an addSbtPlugin away, just like any other plugin.

[Ma27]

fair enough. I was unsure whether to keep the scripts as shortcuts or provide SBT plugins as the only possibe approach to install.
In that case a PR would indeed make no sense :-)