-
Notifications
You must be signed in to change notification settings - Fork 163
Conversation
Why not have it be an opt-in add on package like Pretzel.ScriptCs. Is that
|
Like always you give great advice, I will try that. |
@laedit not always, but at least some of the time :-) It would seem based on what I know about this, that it should be possible to keep the scriptcs dependency out of Pretzel. Maybe allow passing in a catalog, which means just the MEF dependency is sufficient, or have a non-MEF specific plugin interface. |
@@ -102,6 +103,7 @@ private void LoadPlugins(string[] commandArgs) | |||
if (Directory.Exists(pluginsPath)) | |||
{ | |||
catalog.Catalogs.Add(new DirectoryCatalog(pluginsPath)); | |||
catalog.Catalogs.Add(new ScriptCsCatalog(pluginsPath, new ScriptCsCatalogOptions { References = new[] { typeof(DotLiquid.Tag), typeof(Pretzel.Logic.Extensibility.ITag) } })); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead of hardcoding the dependency on scriptcs, you could find the catalog and dynamically load it. There's a host of diff strategies you could use to do this. One could be checking if the assembly exists, and if it does you dynamically load it and instantiate yourself via reflection. You could move ScriptcsCatalogOptions
to a separate Pretzel.ScriptCs.Contracts
package so that Pretzel and the Pretzel.ScriptCs package can reference it, this way Pretzel can still construct and pass in the options easily.
I comment in the PR on one way you might handle this. On Sun, Mar 29, 2015 at 12:36 PM Jérémie Bertrand [email protected]
|
comment[ed] On Sun, Mar 29, 2015 at 12:56 PM Glenn Block [email protected] wrote:
|
Since we already use MEF both for internals and plugins I was thinking to use it again, like loading the |
This reverts commit 440a16a.
That would actually be quite cool, grab the ScriptCs plugin then ScriptCs extensibility just works. |
Yep! On Mon, Mar 30, 2015 at 2:43 AM Jake Ginnivan [email protected]
|
I made a quick and dirty test, but I face the same problem:
Did I miss something? |
I wasn't suggesting Contracts is merged. Pretzel.ScriptCs.Contracts should On Mon, Mar 30, 2015 at 1:36 PM Jérémie Bertrand [email protected]
|
That's what I was trying to do in my second point: Pretzel.ScriptCs.Contracts isn't part of the Pretzel merge, but int that case ILMerge can't work. |
I know very little about ILMerge but can't be much help her. If an ILMerged assembly must have all dependencies merged, then it sounds On Mon, Mar 30, 2015 at 9:09 PM Jérémie Bertrand [email protected]
|
@SimonCropp @distantcam any ideas? Sent from my Windows Phone From: Glenn Blockmailto:[email protected] I know very little about ILMerge but can't be much help her. If an ILMerged assembly must have all dependencies merged, then it sounds On Mon, Mar 30, 2015 at 9:09 PM Jérémie Bertrand [email protected]
— |
Thinking about this more I have an idea of how you can do this which won't require Pretzel to reference the shared contracts directly. A new assembly (say Pretzel.ScriptCs) will contain a ScriptCsCatalogFactory (the answer to all things!). The factory will manufacture a ScriptCsCatalog and return it casted as a ComposablePartCatalog. If Pretzel needs to pass in types and such it can do it via the factory. The factory only exposes primitive / framework types, so it can easily be invoked via reflection. Pretzel will dynamically look for the factory and load it and then invoke it to get the catalog. The code will look something like this... public static class ScriptCsCatalogFactory {
public static ComposablePartCatalog Create(string[] scriptArgs, Type[] references)
{
var options = new ScriptCsCatalogOptions {...};
return new ScriptCsCatalog(options);
} |
ScriptCs had issues whenever I tried folding it into another assembly. There's a few ScriptCs classes that need to be reworked, and then there was a showstopper in Roslyn that meant I couldn't continue. Having said that I was trying this on the version of ScriptCs that used the old version of Roslyn. I haven't tried it since the update. |
Scriptcs still relies on the old version of Roslyn on Windows. You can
|
Praise to @glennblock and shame on me. Following your comment I was so focused on the idea of using a Just for testing purpose I tried to merge the |
Thanks to the recommendations of @ferventcoder, Pretzel will install itself in "C:\tools\Pretzel" (BinRoot or soon ToolsRoot in Chocolatey world) and so does Pretzel.ScriptCs. |
No objections from me |
Fix #217.
Thanks to @vikingcode and @glennblock this PR allow Pretzel to have plugins as easily as to create a *.csx file in the _plugins folder.
But like @vikingcode has already said for some parts:
@shiftkey, @JakeGinnivan your thoughts?