I think just documenting development workflow and process properly will help a great deal. Building Toree is a non-trivial exercise sadly.
On Tue, 31 Jan 2017 at 11:14 Luciano Resende <luckbr1...@gmail.com> wrote: > On Mon, Jan 30, 2017 at 5:47 PM, Jakob Odersky <ja...@odersky.com> wrote: > > > Hi everyone, > > I was wondering how everyone usually develops toree, specifically how > > changes to toree are tested with a jupyter notebook? I couldn't find > > any documentation on the website so I thought I'd ask here. > > > > I tried running the various makefile targets, including `make dev` and > > `make jupyter`, however those targets use a docker image that already > > contains a published upstream version of toree, which thereby > > overrides any changes made to the local version. Running "make > > release", then pip-installing the archive and finally running "jupyter > > install toree" somehow also uses an upstream version of toree. > > > > Is there an easy way to build and install a local source tree? > > > > thanks, > > --Jakob > > > > > It seems that the project has various, and mostly undocumented, utilities > done via make. To me this is good, but don't usually follow the patterns of > projects using a specific build system (e.g. maven, sbt, etc). > > IMHO I believe we should be able to conform with the standards of a basic > sbt project, and enable compile, unit test, package jars and distribution > and publish locally using vanilla sbt commands. And then use and document > the make facilities for more complex tasks such as tests that require > docker, environment setup, build a jupyter env, etc Which will then make > it easy for newcomers that are used to sbt to get started while they learn > about the make magics. > > Thoughts ? > > > -- > Luciano Resende > http://twitter.com/lresende1975 > http://lresende.blogspot.com/ > -- regards Marius van Niekerk
