SBT plugin development cycle

[Mads Hartmann Jensen]

Hi guys, 

Currently when I develop plugins and I want to play around with them I find my approach to be less then optimal (I will explain how I'm currently doing it below). I'm aware that you can use the scripted plugin to create automated tests and that's great but what if you just quickly want to try it out? If you're writing parser combinators to provide tab-completion you also really want to be able to try the plugin and experience the awesome tab-completions, not just test the output/results of running a task/command. 

This is what I'm currently doing

- Create your plugin

- publish-local

- create a "playground" project where you add the plugin 

- toy around with it

This means you have to publish-local every time and in my experience I also had to quit the SBT shell in my "playground" project every time otherwise I would get an exception (that is, if I just ran 'reload' instead).

I would prefer if I could simply compile and load the compiled files as a plugin in the same SBT session. Is this possible? 

Thanks,

Mads

[Josh Suereth]

I create a  project that uses the plugin from source ( val plugin = RootProject(file("/path/to/plugin")) )

I don't bother with SBT on the plugin project at all, but from the test project.  "reload" compiles it and then I'm off to the races.

--
You received this message because you are subscribed to the Google Groups "simple-build-tool" group.
To view this discussion on the web visit https://groups.google.com/d/msg/simple-build-tool/-/7QuqMSD7H9YJ.
To post to this group, send email to simple-b...@googlegroups.com.
To unsubscribe from this group, send email to simple-build-t...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/simple-build-tool?hl=en.

[Doug Tangren]

On Wed, Jan 25, 2012 at 4:15 PM, Josh Suereth <joshua....@gmail.com> wrote:

I create a  project that uses the plugin from source ( val plugin = RootProject(file("/path/to/plugin")) )

I don't bother with SBT on the plugin project at all, but from the test project.  "reload" compiles it and then I'm off to the races.

After Eugene wrote up this awesome peice, http://eed3si9n.com/testing-sbt-plugins, I tend to write the "playground" project as an actual use case for a test using sbt's scripted framework. I guess you can call this tdd for plugin dev but its saved me some pain when switching between sbt releases and finding bugs between versions.

There is a little boiler plate for getting it set up, so I wrote a plugin to generate my plugin tests, https://github.com/softprops/screen-writer. I haven't published it yet. Partially because it's really only useful if you already have sbt's scripted framework added as a plugin. I'm not sure what the current best practices are for plugins that depend on plugins.

My recommendation would be to read and try out some of the ideas in that article ->  http://eed3si9n.com/testing-sbt-plugins

 

[Mads Hartmann Jensen]

Hi Josh, 

Can yon give me some more detail? 

I tired the following: 

object HelloBuild extends Build {
  
  val plugin = RootProject(file("../../yo"))
  
  lazy val root = Project(id = "dawg",
                              base = file("."),
                              settings = Project.defaultSettings)

}

It loads but the plugin command doesn't seem to be accessible. The plugin is simply a "command" plugin 

override lazy val settings = Seq(commands += myCommand)

[Mads Hartmann Jensen]

Hi Doug,

I'm aware of that blog post and I think it's great but I'm currently just looking for something more lightweight for 

example if you just want to demo a plugin or test a plugin with tab-completion (if you want to test the actual completion

and not the plugin as such).

Thanks,

Mads

[Josh Suereth]

Your plugins are declared in the *project of your project*

ie. put that in your project/project/build.scala file and make sure root dependsOn(plugin).

[Mads Hartmann Jensen]

Ah, yes that makes sense. It works like a charm btw, thanks!

[Mark McBride]

Slight wrinkle. Using this

object Plugins extends Build {
lazy val standardProjectPlugin =
RootProject(file("/Users/mmcbride/projects/standard-project"))
lazy val scroogePlugin =
RootProject(file("/Users/mmcbride/projects/sbt-scrooge"))
lazy val root = Project(id = "servo-plugins",
base = file("."))
.dependsOn(standardProjectPlugin, scroogePlugin)
}

Where both standard-project and scrooge use the ScriptedPlugin results in

[info] Loading project definition from
/Users/mmcbride/projects/servo/project/project
[info] Loading project definition from
/Users/mmcbride/projects/sbt-scrooge/project
[info] Loading project definition from
/Users/mmcbride/projects/standard-project/project
[error] AttributeKey ID collisions detected for: 'scripted-scalas'
(sbt.ScriptedPlugin$ScriptedScalas, sbt.ScriptedPlugin$ScriptedScalas)
[error] Use 'last' for the full log.
Project loading failed: (r)etry, (q)uit, (l)ast, or (i)gnore?

Known issue? Bug?

[Josh Suereth]

Known issue.  This is blocking a few things with the community plugin project idea.   basically, we need to fix classloader issues across binary + source dependencies.   Looks to be a dooozey in terms of how we do this, but then again, SBT *allows* source dependencies, which is pretty awesome.

Whoever gets to it first wins I think.  I'll owe you a huge debt.  If not, I'll probably start digging into it in end of feb, when my current tasks are complete. 

- Josh