Autoloading extensions

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Autoloading extensions

pepijnve
I got a request in the asciidoctor-diagram repo to add a better asciidoctor CLI wrapper that autoloads the extension. Seems useful and not really hard to do. I was considering adding 'bin/asciidoctor-diagram' to the gem for this, but then started wondering what kind of mess this would become when you start using a mix of extensions.

So my question to the group now is 'how would you want extension autoloading to work'?
I started thinking about a rubygems plugin style autoloading mechanism that simply loads all extension found on the load path, but maybe no one actually wants that.
Asciidoctor 1.5 adds the -r cli flag, but that still requires explicitly specifying the extensions to load. Is that considered good enough?
That immediately raises the question of version management. Is 'bundle exec' the way to go handle that?

Thanks in advance for any ideas or input,

Pepijn
Reply | Threaded
Open this post in threaded view
|

Re: Autoloading extensions

mojavelinux
Administrator

The solution in 1.5.0 will be to use the -r flag. I have 2 ideas about where to go next from there.

. A configuration file that defines arguments that get passed to the cli, typically attributes and options, but -r values fit here too. hyla can also fill in here.

. An implicit association between discovered extension groups and the extensions attribute.

The second option allows Asciidoctor to load extensions defined either in the document or passed as an attribute to the processor. For instance, I picture something like:

```
= Document Title
:extensions: diagram, ui, textql

content
```

The extensions would be auto-discovered, but not activated unless listed in the extensions attribute.

This is why the extension group name added in 1.5.0 is important. This name is likely what we'll use to locate extensions to activate.

I'd hold off on adding a wrapper script since I don't really want to get into having a bunch of different commands to support. It should be clear that's just a short term stop gap for 0.1.4.

-Dan

On Feb 26, 2014 1:49 PM, "pepijnve [via Asciidoctor :: Discussion]" <[hidden email]> wrote:
I got a request in the asciidoctor-diagram repo to add a better asciidoctor CLI wrapper that autoloads the extension. Seems useful and not really hard to do. I was considering adding 'bin/asciidoctor-diagram' to the gem for this, but then started wondering what kind of mess this would become when you start using a mix of extensions.

So my question to the group now is 'how would you want extension autoloading to work'?
I started thinking about a rubygems plugin style autoloading mechanism that simply loads all extension found on the load path, but maybe no one actually wants that.
Asciidoctor 1.5 adds the -r cli flag, but that still requires explicitly specifying the extensions to load. Is that considered good enough?
That immediately raises the question of version management. Is 'bundle exec' the way to go handle that?

Thanks in advance for any ideas or input,

Pepijn


If you reply to this email, your message will be added to the discussion below:
http://discuss.asciidoctor.org/Autoloading-extensions-tp1548.html
To start a new topic under Asciidoctor :: Discussion, email [hidden email]
To unsubscribe from Asciidoctor :: Discussion, click here.
NAML
Reply | Threaded
Open this post in threaded view
|

Re: Autoloading extensions

pepijnve
I would prefer to not do the wrapper script thing either; that was kind of why I asked the question. This path leads to wrapper scripts per extension which only solves the single extension case. It's back to square one when you need more than one extension.

The second option you suggested (doc attribute) is what I had in mind as well. Sounds like a fun thing to implement. It would be great to try and get this in 1.5.0. I'm eager to try and get something like this working. The only bit I'm struggling with is how to manage versions. If multiple versions of asciidoctor and/or extension gems are installed you want to be sure you're activating the right one.
One option is to use bundler to figure out. Put a Gemfile besides document, let asciidoctor load that and use the information from the Gemfile (.lock to be correct) to handle version selection.
Alternatively we could write custom logic to do this and try to pick the most recent version of an extension gem that is compatible with the running asciidoctor version. Not sure how to do that best though. Read the gem spec and check if the asciidoctor dependency requirements are compatible with the running asciidoctor version?

How would you handle extension discovery btw? Scan all gems for a well-known file (e.g., asciidoctor-extension) using Gem.find_files?