[ANN] Clojure 1.9 / clojure.spec split

[Alex Miller]

We are moving spec out of the Clojure repo/artifact and into a library to make it easier to evolve spec independently from Clojure. While we consider spec to be an essential part of Clojure 1.9, there are a number of design concerns to resolve before it can be finalized. This allows us to move towards a production Clojure release (1.9) that depends on an alpha version of spec. Users can also pick up newer versions of the spec alpha library as desired. Additionally, this is a first step towards increased support for leveraging dependencies within Clojure.

We will be creating two new contrib libraries that will contain the following (renamed) namespaces:

org.clojure/spec.alpha
    clojure.spec.alpha          (previously clojure.spec)
    clojure.spec.gen.alpha      (previously clojure.spec.gen)
    clojure.spec.test.alpha     (previously clojure.spec.test)

org.clojure/core.specs.alpha
    clojure.core.specs.alpha    (previously clojure.core.specs)

In most cases, we expect that users have aliased their reference to the spec namespaces and updating to the changed namespaces will only require a single change at the point of the require.

How will ClojureScript's spec implementation change?

ClojureScript will also change namespace names to match Clojure. Eventually, the ClojureScript implementation may move out of ClojureScript and into the spec.alpha library - this is still under discussion.

Why do the libraries and namespaces end in alpha?

The "alpha" indicates that the spec API and implementation is still subject to change.

What will happen when the spec api is no longer considered alpha?

At that point we expect to release a non-alpha version of the spec library (with non-alpha namespaces). Users may immediately begin to use that version of spec along with whatever version of Clojure it depends on. Clojure itself will depend on it at some later point. Timing of all these actions is TBD.

Will the library support Clojure 1.8 or older versions?

No. spec uses new functions in Clojure 1.9 and it has never been a goal to provide spec for older versions. Rather, we are trying to accelerate the release of a stable Clojure 1.9 so that users can migrate forward to a stable production release with access to an alpha version of spec, and access to ongoing updated versions as they become available.

[Tatu Tarvainen]

Thanks for the update.

This seems like a good decision that moves Clojure forward without tying your hands as to the future direction of spec.

[Leon Grapenthin]

Thanks for the update, this seems like a good decision allowing things to evolve more quickly.

Does that also mean that there are no breaking changes intended to current non .alpha namespaces/APIs? 

Kind regards,

 Leon

[Alex Miller]

On Wednesday, April 26, 2017 at 11:32:39 AM UTC-5, Leon Grapenthin wrote:

Thanks for the update, this seems like a good decision allowing things to evolve more quickly.

Does that also mean that there are no breaking changes intended to current non .alpha namespaces/APIs? 

1.9 itself is still in alpha and so there may be breaking changes to anything new in 1.9 (new predicate functions, etc). Hopefully we will be able to proceed more rapidly towards a final release of 1.9 though.

[Sean Corfield]

Whilst this is rather disruptive for current users of clojure.spec, I understand and appreciate the goal.

 

I hope that the new org.clojure/spec.alpha will be made available for a few days ahead of actually removing it from Clojure 1.9 so that those of us already using it and doing multi-version against master-SNAPSHOT will have a few days to update our code rather than just see our dev builds break and get blocked while we’re forced to make this code change?

 

Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Colin Fleming]

Doesn't this mean that Clojure and spec will be mutually dependent, i.e. a dependency cycle? Is that likely to cause problems for any tooling?

clojure+unsubscribe@googlegroups.com

For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.

To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to

clojure+unsubscribe@googlegroups.com

For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.

To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscribe@googlegroups.com.

[Alex Miller]

On Wednesday, April 26, 2017 at 6:27:08 PM UTC-5, Colin Fleming wrote:

Doesn't this mean that Clojure and spec will be mutually dependent, i.e. a dependency cycle?

Yes

 

Is that likely to cause problems for any tooling?

No? :)  Feedback wanted, though if you find that to not be the case.

We haven't landed the patch back into Clojure yet but Clojure's inclusion of the spec.alpha dependency will exclude its Clojure dependency and I don't think this cycle causes any problems as far as I can tell. The initial spec.alpha build will be source-only. Once the namespaces are removed from Clojure, subsequent builds will be AOT'ed. Once you get to that point, you've essentially got the same pile of classes (split into 2 jars) that we have now, so it's hard for me to see where that goes wrong.

[Alex Miller]

[org.clojure/spec.alpha "0.1.94"]

[org.clojure/core.specs.alpha "0.1.10"]

are available now.

[Alex Miller]

I guess I should say again that no one needs to depend directly on these - Clojure will include them via dependency. At some point there will may be a newer version of these libs you wish to use than the one included by Clojure and only in that case would you need to include it directly.

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to

clojure+unsubscribe@googlegroups.com

For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---

You received this message because you are subscribed to a topic in the Google Groups "Clojure" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojure/10dbF7w2IQo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to clojure+unsubscribe@googlegroups.com.

[Sean Corfield]

I switched the World Singles’ codebase over to using org.clojure/spec.alpha today with no problems. Since we always `:require .. :as` it was an easy global find’n’replace (well, three of them – one for each namespace change needed). We’re also explicitly depending on the 0.1.94 release (so our build system will automatically track when a new version appears and flag that for us).

 

What would be the use case for users to explicitly depend on core.specs.alpha given that is only used internally by Clojure?

 

Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood

 

On 4/26/17, 6:02 PM, "Alex Miller" <clo...@googlegroups.com on behalf of al...@puredanger.com> wrote:

 

I guess I should say again that no one needs to depend directly on these - Clojure will include them via dependency. At some point there will may be a newer version of these libs you wish to use than the one included by Clojure and only in that case would you need to include it directly.

On Wed, Apr 26, 2017 at 7:54 PM, Alex Miller <al...@puredanger.com> wrote:

[org.clojure/spec.alpha "0.1.94"]

[org.clojure/core.specs.alpha "0.1.10"]

 

are available now.

On Wednesday, April 26, 2017 at 1:28:05 PM UTC-5, Sean Corfield wrote:

Whilst this is rather disruptive for current users of clojure.spec, I understand and appreciate the goal.

 

I hope that the new org.clojure/spec.alpha will be made available for a few days ahead of actually removing it from Clojure 1.9 so that those of us already using it and doing multi-version against master-SNAPSHOT will have a few days to update our code rather than just see our dev builds break and get blocked while we’re forced to make this code change?

 

Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood

 

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to

clojure+u...@googlegroups.com

For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to a topic in the Google Groups "Clojure" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojure/10dbF7w2IQo/unsubscribe.

To unsubscribe from this group and all its topics, send an email to clojure+u...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

 

--

You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to

clojure+u...@googlegroups.com

For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---

You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com.

[Tamas Herman]

What problems would it pose if the alpha status would be reflected in the version number of org.clojure/spec,

just like it is the case with org.clojure/clojure rightnow, which is 1.9.0-alpha15?

I've seen the Spec-ulation Keynote from Rich and this step feels like an experiment

to try out the idea of encoding the api version of a library in the name of the library.

Is that correct?

-- 

  tom

[Alex Miller]

On Thursday, April 27, 2017 at 3:05:26 AM UTC-5, Tamas Herman wrote:

What problems would it pose if the alpha status would be reflected in the version number of org.clojure/spec,

just like it is the case with org.clojure/clojure rightnow, which is 1.9.0-alpha15?

At some future point, there will be a non-alpha version of spec. At that point it is effectively (and likely actually) a different library. Marking this one explicitly as alpha allows it to continue to exist and be in use by alpha users without a breaking change. Non-alpha users can switch to a new library with new namespaces.

 

I've seen the Spec-ulation Keynote from Rich and this step feels like an experiment

to try out the idea of encoding the api version of a library in the name of the library.

Is that correct?

Kind of, but this is a little different in that we're talking about alpha (breaking change possible) vs non-alpha here.

[Steve Miner]

Before the spec split, the basic way to invoke Clojure at the command line was:

% java -cp clojure.jar clojure.main

Documented here: https://clojure.org/guides/getting_started

Is that still the intended usage with 1.9 going forward?

When I try it with 1.9-alpha16, I get an error:

Exception in thread "main" java.lang.ExceptionInInitializerError

at clojure.main.<clinit>(main.java:20)

Caused by: java.io.FileNotFoundException: Could not locate clojure/spec/alpha__init.class or clojure/spec/alpha.clj on classpath.

As a work-around, I grabbed the spec jars and added them to the classpath.  That worked to get me to the REPL.

However, I noticed that I get an error from the doc function.  So something is still not right with spec.

% java -cp clojure.jar:spec.alpha-0.1.94.jar:core.specs.alpha-0.1.10.jar clojure.main

Clojure 1.9.0-alpha16

user=> (doc +)

-------------------------

clojure.core/+

([] [x] [x y] [x y & more])

  Returns the sum of nums. (+) returns 0. Does not auto-promote

  longs, will throw on overflow. See also: +'

ClassNotFoundException clojure.spec.alpha$get_spec  java.net.URLClassLoader.findClass (URLClassLoader.java:381)

user=> *e

#error {

 :cause "clojure.spec.alpha$get_spec"

 :via

 [{:type java.lang.NoClassDefFoundError

   :message "clojure/spec/alpha$get_spec"

   :at [clojure.repl$print_doc invokeStatic "repl.clj" 109]}

  {:type java.lang.ClassNotFoundException

   :message "clojure.spec.alpha$get_spec"

   :at [java.net.URLClassLoader findClass "URLClassLoader.java" 381]}]

 :trace

 [[java.net.URLClassLoader findClass "URLClassLoader.java" 381]

  [java.lang.ClassLoader loadClass "ClassLoader.java" 424]

  [sun.misc.Launcher$AppClassLoader loadClass "Launcher.java" 331]

  [java.lang.ClassLoader loadClass "ClassLoader.java" 357]

  [clojure.repl$print_doc invokeStatic "repl.clj" 109]

  [clojure.repl$print_doc invoke "repl.clj" 83]

  [clojure.lang.Var invoke "Var.java" 381]

  [user$eval1596 invokeStatic "NO_SOURCE_FILE" 1]

  [user$eval1596 invoke "NO_SOURCE_FILE" 1]

  [clojure.lang.Compiler eval "Compiler.java" 6977]

  [clojure.lang.Compiler eval "Compiler.java" 6940]

  [clojure.core$eval invokeStatic "core.clj" 3187]

  [clojure.core$eval invoke "core.clj" 3183]

  [clojure.main$repl$read_eval_print__9835$fn__9838 invoke "main.clj" 242]

  [clojure.main$repl$read_eval_print__9835 invoke "main.clj" 242]

  [clojure.main$repl$fn__9844 invoke "main.clj" 260]

  [clojure.main$repl invokeStatic "main.clj" 260]

  [clojure.main$repl_opt invokeStatic "main.clj" 324]

  [clojure.main$main invokeStatic "main.clj" 423]

  [clojure.main$main doInvoke "main.clj" 386]

  [clojure.lang.RestFn invoke "RestFn.java" 397]

  [clojure.lang.AFn applyToHelper "AFn.java" 152]

  [clojure.lang.RestFn applyTo "RestFn.java" 132]

  [clojure.lang.Var applyTo "Var.java" 702]

  [clojure.main main "main.java" 37]]}

I think it would be nice to have an inclusive jar as before.  Or we could make Clojure 1.9 tolerant of not having spec available, perhaps by stubbing out the basics of spec.  Maybe give a warning that explains how to get the spec jars.

Steve Miner

[Alex Miller]

Going forward, you will need to create your classpath with three jars: Clojure, spec.alpha, and core.specs.alpha. There are some more things planned in this area still to come. We do not currently plan to build a combined jar but things may change. The web page in question will be updated when 1.9 releases.

The error you are seeing with doc is a known issue due to spec.alpha not being aot compiled. A newer version (0.1.108) of spec.alpha is available that fixes the issue. Note that this kind of update is exactly why the jars are split - you can update the libs more frequently than the Clojure version.

[Steve Miner]

On May 3, 2017, at 7:37 PM, Alex Miller <al...@puredanger.com> wrote:

A newer version (0.1.108) of spec.alpha is available that fixes the issue. Note that this kind of update is exactly why the jars are split - you can update the libs more frequently than the Clojure version.

Thanks. The updated spec.alpha works for me.

[Matching Socks]

>   Additionally, this is a first step towards increased support for leveraging dependencies within Clojure.

What do you have in mind?