Does anyone know how I can add a GitHub Packages resolver to an Ammonite script?
I'm quite used to using GitHub Packages with sbt, but we use the sbt-github-packages plugin, which makes it very easy to add a GitHub Packages resolver to a build.sbt file. E.g., in build.sbt, I merely include:
resolvers += Resolver.githubPackages("myCompany")
Since I can't use the sbt-github-packages plugin with Ammonite, I'm sure that the answer is significantly more complicated with Ammonite.
With the sbt-github-packages plugin, for authentication, I have my GitHub token in an environment variable called GITHUB_TOKEN, and an Ammonite solution would also have to perform the proper authentication.
Related
I want to add a scala Library into my build.sbt dependencies. Here is the sample package, and it publishes in Github registry.
This library is not from the official maven repository, I could not find it in Maven repository. I think it could not install in there.
<dependency>
<groupId>gjuoun</groupId>
<artifactId>hellopackage_2.13</artifactId>
<version>0.1.6</version>
</dependency>
And then, I find it should belong to ghcr.io, so I add this line to my build.sbt.
resolvers += "hellopackage" at "http://ghcr.io/gjuoun/hellopackage"
It does not work at all. I could not use it. I am looking for a better to install this package by using resolvers without addSbtPlugin. (I don't want to use pom.xml if possible)
Thanks for any help.
You can use Daniel Spiewak's sbt plugin sbt-github-packages.
See details in http4s-request-signer_2.13 dependency is not downloaded from central repository
If you don't want to use sbt plugins and you're interested only in building your project but not publishing it (to Github registry) then you can just add to build.sbt
// specifying repo is optional: "_"
resolvers += "Another maven repo" at "https://maven.pkg.github.com/gjuoun/_"
credentials += Credentials(
"GitHub Package Registry",
"maven.pkg.github.com",
"_", // user is ignored
"ghp_YOUR_GITHUB_TOKEN"
)
libraryDependencies += "gjuoun" %% "hellopackage" % "0.1.6"
That's basically what the plugin does.
For security reasons it's better not to hardcode the token in build.sbt but for example put it into environment variable
credentials += Credentials(
"GitHub Package Registry",
"maven.pkg.github.com",
"_",
sys.env("GITHUB_TOKEN")
)
You can check that without credentials sbt will not be able to build your project.
The thing is that although manually you can download a JAR from Github in your browser without authentification (and put it into lib), this doesn't mean that Github allow reading, resolving, downloading programmatically via API (sbt, ivy, coursier) without authentification.
You need authentification only the first time. Then JAR will be cached locally in ~/.cache/coursier/v1/https/maven.pkg.github.com/gjuoun/_/gjuoun/hellopackage_2.13/0.1.6/ and will be taken from there further on.
Several quotes:
A valid Github token shouldn't always be mandatory #28
GitHub requires a token even for read-only access to packages.
Credentials should remain optional #34
So the problem I have with this is the fact that resolution from GitHub Packages also requires a token. You can't just download a package unauthenticated, meaning that credentials are necessary at all times regardless of whether or not you're publishing. Honestly, this is a thing that GitHub needs to fix.
I work with a variety of SBT projects and not all of them share the same repositories/resolvers. I would like to be able to store the repositories configuration inside each project so that I can also build other people's projects without overriding the default (or theirs) repositories and sbt configuration.
Using the ~/.sbt/repositories is not an option since that is per user and not per project. I have tried passing parameters to sbt and that works; e.g. sbt compile -Dsbt.boot.properties=build/sbt.boot.properties. However, that requires people to remember this flag and type it/alias it every time.
Is there any way to get sbt to read configuration, or flags like the above, from its current directory? Thanks!
Have you tried http://www.scala-sbt.org/0.13/docs/Resolvers.html?
Resolvers for Maven2 repositories are added as follows:
resolvers += "Sonatype OSS Snapshots" at "https://oss.sonatype.org/content/repositories/snapshots"
This is the most common kind of user-defined resolvers. The rest of
this page describes how to define other types of repositories.
I have an internal SBT plugin which sets up a lot of common aspects of my build. One of those is my setup to add my Artifactory credentials and resolvers. I typically publish the plugin locally so that my build can resolve it and then pull the remaining dependencies from my Artifactory repositories.
For deploying to Heroku, I planned to copy the published artifacts from my .ivy2 repo to a subfolder of the project. However, though I can get this to work locally using both Resolver.file and Resolver.url, I cannot get this to work once I push to Heroku. I even tried it as an unmanaged dependency but still unresolved in Heroku.
Does anyone know the magic spell for achieving this on Heroku?
I have attempted following in project/plugins.sbt:
Resolver.url.("local-plugins", url(s"file///${baseDirectory.value}/plugins"))(Resolver.ivyStylePatterns)
Resolver.file("local-plugins", file("plugins")(Resolver.ivyStylePatterns)
unmanagedBase := baseDirectory.value / "lib"
I recommend two different approaches:
Use the sbt-heroku plugin instead of deploying with Git. You can use local dependencies this way.
Deploy your plugin to BinTray. It's fairly easy, free, and worth the trouble.
I revisited this again today and the following worked:
In plugins.sbt:
resolvers += Resolver.file("local-plugins", file("local-plugins"))(Resolver.ivyStylePatterns)
My project also contains a local-plugins/ directory in the working folder which holds the published artifacts.
There is a port of shapeless library to scala-js (https://github.com/alexander-myltsev/shapeless). I need to publish artifact properly with fewer possible dependencies to original shapeless.
Now I forked Miles Sabin's repo, and added changes required to generate scala-js library: add scalajs-sbt-plugin, tune build.scala, add bintray-sbt-plugin.
It is wrong to ask shapeless maintainers to merge my branch because scala-js could broke their build.
On the other hand I'd like to have minimal dependencies to original repo as well. Theoretically and ideally what I'd like is to create, say, shapeless-scalajs sbt-project from scratch. Then reference somehow original shapeless library. And then derive from shapeless-build-scala with required overrides to build it against scala-js and publish to my bintray.
I believe in almighty sbt :) What are my options to solve this task?
I think the easiest way is (no sbt hackery involved):
Fork shapeless
Create Scala.js branch
Change build files as you need. That is, modify the shapelessCore project directly as in your PR. (add scalaJSSettings, your repo coordinates)
Commit
Publish shapeless to your maven central
When a new version of shapeless comes out, just merge shapeless/master with your scala.js branch. If no changes happened to the build file, this will merge just fine.
Re-publish
This will be way easier than an sbt project that depends on an external project (which is doable, but doesn't directly allow you to reuse settings etc.)
I'm dealing with two repos:
- A github repo that contains a bunch of text files.
- A scala project that would like to read those text files.
I would like to use SBT to download the contents of the github repo as a build dependency.
I wouldn't mind if SBT supplied either a path (into the ivy repo?) for the project to use or build them into the projects available resources - or any other way that will just work. I'm aiming for something automatic; clearly there are ways I could do this manually.
If you talk about a bunch of text files like *.property for example that used as dependency for your project (do you really want download them every time?) you may use sbt.IO.download(url: URL, to: File). Just create task and add to project definition compile <<= (compile in Compile) dependsOn myDownloadTask After that you may process them as regular local files ;-).
IMHO you understand that you may add custom logic like caching or page parsing or REST request to GitHub to your project definition. At last you may create your own SBT plugin - there are few video tutorials "How to create SBT plugin in 5 minutes" on YouTube.