Add a command-line interface?

[abigailbunyan]

typesafehub/zinc has a command-line interface, which makes it simple to integrate into build systems that don't run on the JVM. We use this in our SCons-based build system, and the lack of a command-line interface is blocking us upgrading to sbt/zinc.

It's mentioned in #80 that this is a to-do item, but it hasn't been touched since April 2016. Is this still a planned item?

[jvican]

As I said in Gitter, this isn't in the scope of zinc itself. Those that want the equivalent of typesafehub/zinc (basically, a nailgun integration for zinc) should use Bloop https://scalacenter.github.io/bloop/.

[dwijnand]

I don't see how providing a main for zinc is out of scope of this project.

Why do you see it as out of scope?

[jvican]

For the same reason it's been maintained in typesafehub/zinc (an independent repo) for years and because what he asks for is called Bloop.

[dwijnand]

The reasons for typesafehub/zinc were because the incremental compiler was internal to sbt.

Bloop adds a client/server or daemon functionality on top of Zinc. But I don't see why Zinc itself can't ship with a useable main.

[jvican]

Bloop adds a client/server or daemon functionality on top of Zinc.

What do you mean? Bloop can be invoked without the client/server architecture. It has a normal main that supports it, just as Zinc would do.

I think it's important that we don't duplicate efforts in this area, as you said in the Scala Contributors summit, which was a good point. This would only duplicate work and add maintenance overhead to a repo in which there's not a lot of activity rather than improving the precision of the incremental compiler.

[dwijnand]

Indeed I care about not duplicating efforts.

In my mind I was envisioning any "main-y" things added here to be re-usable by Bloop.

That is because I think of Zinc as something that should have a CLI, not as simply a library, with Bloop going much further and adding the client/server architecture.

[jvican]

That is because I think of Zinc as something that should have a CLI, not as simply a library, with Bloop going much further and adding the client/server architecture.

Bloop doesn't force the client/server architecture. You can still use bloop as a normal client -- with no server whatsoever https://github.com/scalacenter/bloop/blob/master/frontend/src/main/scala/bloop/Cli.scala#L19-L23. Even if this CLI was added to Zinc, there would be nothing bloop could reuse.

On top of that, I don't see myself much value to having the incremental compiler have a CLI without an interface to represent the DAG of projects (which is exactly what bloop does). Incrementality only makes sense in the context of a build tool.

[dwijnand]

Even if this CLI was added to Zinc, there would be nothing bloop could reuse.

Bloop could forward to Zinc's CLI main.

I don't see myself much value to having the incremental compiler have a CLI without an interface to represent the DAG of projects

I don't see why you need a DAG of projects. Just: given a set of source files, a set of class files and a set of analysis files, compile.

[jvican]

Bloop couldn't forward to zinc's CLI main because bloop has its own wrappers around Zinc.

I don't see why you need a DAG of projects. Just: given a set of source files, a set of class files and a set of analysis files, compile.

My point is that such interface is limited and only useful in the context of one project. At the moment you want incrementality across different projects, it's when you need project DAGs.

--

I've already said all the arguments I have against this feature. I don't have anything else to add to this discussion.

[dwijnand]

Bloop couldn't forward to zinc's CLI main because bloop has its own wrappers around Zinc.

Right, it would need to rewire those wrappers.

My point is that such interface is limited and only useful in the context of one project. At the moment you want incrementality across different projects, it's when you need project DAGs.

Sure. And that's when you decide to use Bloop, for instance.

I've already said all the arguments I have against this feature. I don't have anything else to add to this discussion.

Cool. I'm all done too.

[abigailbunyan]

Why do you see it as out of scope?

For the same reason it's been maintained in typesafehub/zinc (an independent repo) for years

typesafehub/zinc is deprecated, and sbt/zinc is recommended as a continuation of typesafehub/zinc in its readme.

My point is that such interface is limited and only useful in the context of one project. At the moment you want incrementality across different projects, it's when you need project DAGs.

And we've been happily using that interface for years now integrated into our build system, and it's a much simpler integration than integrating Bloop would be.

[jvican]

@abigailbunyan I don't think anybody from the core team is going to work on this any time soon. I do care about your use case in your own build tool. What could I do in bloop to make integrating with it easier?

[abigailbunyan]

Good question. The problems aren't insurmountable and I haven't investigated too hard, but here's the pain points I can see in changing from Zinc to Bloop:

1. We currently use Zinc via Apache Ivy, so nobody has to install it to use it. I don't know if that's possible with Bloop, but if it is it'd be great to have it documented (ie. the artifact name and main class name) on the install page.
2. Bloop requires generating a config file; this would add an extra step in our build system. With Zinc we just pass all the source files on the command line and the directory for generated classes, it finds the analysis files and compiles what's new. The documentation on the configuration file format is a little light too, there's a schema available but a more fully-featured guide with examples would make integrating easier.

Being able to use Zinc like this gives us a simple integration, which is preferable for us as Scala is one of only four languages in this project.

[jvican]

We currently use Zinc via Apache Ivy, so nobody has to install it to use it. I don't know if that's possible with Bloop, but if it is it'd be great to have it documented (ie. the artifact name and main class name) on the install page.

How do you install typesafehub/zinc now? Is it already installed in your non-JVM build tool? Installing bloop should be similar to using typesafehub/zinc. You can install the server via Apache Ivy (e.g. resolving ch.epfl.scala:bloop-frontend_2.12:1.0.0) and the client is a python binary that you can run from your build tool.

The only difference compared to typesafehub/zinc is that the client will not start the server on its own. This is something we can easily implement if it's a blocker for you.

Bloop requires generating a config file; this would add an extra step in our build system. With Zinc we just pass all the source files on the command line and the directory for generated classes, it finds the analysis files and compiles what's new. The documentation on the configuration file format is a little light too, there's a schema available but a more fully-featured guide with examples would make integrating easier.

Do you mean a whole example of a configuration file? Maybe we can add that. Note that you do have examples of contents for every field in the JSON schema though.

For your use case, you can easily generate a configuration file because most of the fields are constants and you need almost no configuration at all. These are the mandatory fields (also present in the JSON schema, you need to click on the type of the fields to see them as they are folded by default) for the configuration file of a project:

1. version field.
2. project field.
   2.1. name field
   2.2. directory field
   2.3. sources field (it can be both files and dirs)
   2.4. dependencies field (if the project depends on other projects in a build)
   2.5. classpath field
   2.6. out field (the target directory)
   2.7. classesDir field (the classes directory, usually inside the target)

Here's a gist showing an example with the mandatory fields.

In your case, you not even need to depend on our config artifact, you can stringify everything (the compatibility of the configuration format is taken seriously, so expect no breakage here so long as you include these mandatory fields).