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?