Merge the two ob-scala implementations

[tarsius]

I previously raised this issue on an old pull request. I am opening this new issue so that you don't forget about this.

[fommil]

@reactormonk can you please look into this?

[reactormonk]

@fommil How would you specify the inf-ensime buffer to talk to? Would :session <buffer-name> work? With an added magic value that looks for an ensime buffer according to the current directory.

[fommil]

I don't really have any preferences on this. We're assuming that ensime is available so just call functions as normal... if ensime is not available then it will fail. You may need to add some warning suppressions as a result of this.

[hvesalai]

Are we really assuming ensime is available. At least I still use scala-mode from time to time without ensime. I think scala-mode should at install and work even without ensime even if some functionality would not be available.

[fommil]

@hvesalai we're never going to have a circular dependency between ensime and scala-mode. But the scala org-mode may have some features that are only available if ensime is available. I think it's for the repl support, if I recall, which is really just the .ensime parser (not the server component).

[reactormonk]

The current ob-scala is launching an ensime-inf-run-scala to load in the project, so you can use dependencies. The initial ob-scala just goes via scala binary, so you can't depend on anything.

[fommil]

certainly ob-scala should be moved into the org-mode. @reactormonk do you think you'd be able to find some time to do that anytime in the next few weeks / months?

[tarsius]

Any progress on this?

Please also note that Bastien (@bzg) prefers to remove such things out of the org repository, see https://github.com/larstvei/ox-gfm/issues/14#issuecomment-257102966. Maybe in this case the best thing would be to use a third, dedicated repository.

[sauyon]

Is there really any reason to use ensime-inf-run-scala instead of having a header argument that allows dependencies to be added inside the org file itself?

It makes no sense to require the full-blown sbt/ensime stack when all that's needed is a simple -cp flag....

[reactormonk]

You'll still have to download the dependencies. Coursier could take care of that.

[fommil]

ensime-inf-run-scala doesn't depend on the sbt or the ensime stack. It only requires a .ensime file to exist, which defines where the jars are that go into that -cp flag.

I would be happy for somebody to move the scala REPL code from ensime into a separate emacs package (and for sbt-mode to use it instead of bundle its own REPL mode) but it would be a lot of work instead of just doing a dynamic dependency lookup.

[sauyon]

Is it unexpected that it asks me to run the server when I attempt to run code then?

(Just a bit frustrated, mostly because the ensime server refuses to start for me)

[fommil]

yes, that's definitely unexpected. It might be trying to generate a .ensime for you by calling out to sbt? That sounds like something that should be opt-in.

[tarsius]

Could someone please look into this again?

I am afraid I cannot help because I don't use scala and I don't understand the above discussion. It seems about dependencies between elisp libraries (that part understand) as well as about how the elisp part (I assume this implementation) communicates with the scala part / repl.

While that discussion might be relevant to the following, I would still like to reiterate the original issue I was trying to get resolved by opening this issue.

There are currently two ob-scala.el implementations. I was hoping that one of these implementations would be deprecated in favor of the other.

Both implementations might lack some features that the other has, and it might be a good idea to start by creating a list of such unique features.

[fommil]

it seems the authors of the files don't really care, so I say we just kill one randomly and let them fight it out.

[tarsius]

:smiley: Yeah...

Okay, so I think ob-scala should ideally live in its own repository. But since there is no such implementation, my second preference is for it to live in "a scala repository", as opposed to in the Org repository.

@bzg do you think simply deleting the version in the Org repository would be acceptable? If so, then could you please do it?

Otherwise please delete the implementation from this repository @fommil.

[fommil]

I am all for deleting it from org.

In fact I can't seem to get org to work these days for markdown export, I should really look into that. I've been using the version distributed with emacs for ages.

Thanks for the patience @tarsius

[bzg]

Yes, I will look into this tomorrow. Thanks!

[bzg]

Actually, I expected to see ob-scala listed in GNU ELPA or MELPA.

Is it available as an Emacs package somewhere?

I don't think it is a good idea to delete it from Org before it is available as a package elsewhere.

PS: Note that I will be offline for one week.

[fommil]

@bzg it's part of scala-mode. It does not make sense to distribute it separately from scala-mode.

[bzg]

Ok, done. Copying @unjello to notify him than ob-scala.el is to be removed from the next stable release of org-mode and to notify you guys in case you want to exchange on how to merge the two versions of ob-scala.el. Thanks.

[fommil]

Awesome, thanks @bzg. I am writing a book on Scala using org-mode https://leanpub.com/fp-scala-mortals and making heavy use of ob-scala so thank you all for such an amazing piece of free software! That said, current org-mode master is not working for me when I try to export markdown, so I suspect I may go down the rabbit hole if I try to get it set up at this point. I will try to minimise that problem and report / fix. To anybody who wants my help in getting ob-scala.el working better with org, your best bet is helping me to fix that problem.

[bzg]

Yes, thanks in advance for reporting your problem with the Markdown export!

[tarsius]

Thanks!

[mexisme]

In searching for an issue I was having getting Cannot open load file: No such file or directory, ob-scala errors, this issue was one of the first found.

Just wanted to link to #155 in here to make it easier for people to learn that ob-scala has been removed.