[ANN] Korma SQL ported to ClojureCLR

[Aaron]

I needed something quick like Korma for my .NET work, so I ported it to ClojureCLR.  The code is here: https://github.com/aaronc/Korma.net.  So far only MySql is supported.

Right now, there is nothing like leiningen for .NET so no build and distribution yet.  Also, most of the code for the JVM version ported over unchanged - I mainly had to implement some basic support for ADO.NET.  So, potentially a library such as this could be maintained under one source tree and some sort of conditional loading could be used depending on which implementation of Clojure was executing (JVM, CLR, Python, etc.).  I see that a JIRA ticket was opened for this a while ago: http://dev.clojure.org/jira/browse/CLJS-27 and I also found this thread: https://groups.google.com/forum/?fromgroups#!topic/clojure/M9NKAui3Z0Q.  Any new thoughts as to what the canonical way for supporting multiple implementations should be?

[Rick Beerendonk]

Right now, there is nothing like leiningen for .NET

Did you take a look at NuGet?

http://nuget.codeplex.com/

 

[Aaron]

I think it's a goal to get Clojure.dll on nuget soon, but it hasn't happened yet.  Hopefully soon.  Still, we'll need a good build system for ClojureCLR that does everything that lein does.  But, I don't think that should be that complicated if nuget is used as a basis.

[dmiller]

On Friday, April 6, 2012 6:23:43 PM UTC-5, Aaron wrote:

I think it's a goal to get Clojure.dll on nuget soon, but it hasn't happened yet.  Hopefully soon.  Still, we'll need a good build system for ClojureCLR that does everything that lein does.  But, I don't think that should be that complicated if nuget is used as a basis.

ClojureCLR on nuget is a goal, and one fairly easy to accomplish, in the sense of just packaging the DLLs and getting them posted.  However, the primary use of NuGet is pulling dependencies into projects in Visual Studio.    That means spending some time working the vsClojure Visual Studio extension to get all the pieces playing together.

When people say "lein on .net"  or "good build system for ClojureCLR", is Visual Studio integration usually meant, or is there a standalone experience being coveted?

[Aaron]

I can comment on what is important to me for the build system.  First, being able to embed .clj files in an existing C# project as embedded resources (as has been enabled by a couple forks - https://github.com/ralmoritz/clojure-clr and my own - https://github.com/aaronc/clojure-clr) is extremely useful.  This takes care of most of my day to day usage.  For editing, I am actually using emacs *inferior-lisp*, however, and just using Visual Studio to embed the files into a DLL.  I actually haven't been using vsClojure.

Now, in order to create a library ecosystem for ClojureCLR, I think something like leiningen is necessary.  This could simply be a library whose job is to make sure that any assemblies that need to be downloaded are downloaded (possibly even at runtime) and to call assembly-load for all necessary assemblies.  I find it inelegant to call assembly-load* manually from my code.  So having a leiningen-like frontend that would be the main entry point for all .dll's containing Clojure code (whether that's embedded .clj's or AOT-compiled code) would be nice.  We could use a project.clj like format with some specific .NET/nuget features like strong names and semantic version specifiers.  This project.clj could then be embedded in any Clojure library .DLL that is distributed and be used to load transitive dependencies for these libraries.  I don't think it would be too hard to write this initial dependency loading part of the build tool and it could probably be done in such a way that it plays nice with vsClojure projects, mixed C#/Clojure projects, and possibly used standalone.

[rippinrobr]

David,

I do most of my ClojureCLR dev in emacs so having the same experience
as you do with lein would be ideal. Integration with vsClojure would
be nice to have for me but not a must.

-Rob