{"action":"created","issue":{"url":"https://api.github.com/repos/technomancy/leiningen/issues/1956","labels_url":"https://api.github.com/repos/technomancy/leiningen/issues/1956/labels{/name}","comments_url":"https://api.github.com/repos/technomancy/leiningen/issues/1956/comments","events_url":"https://api.github.com/repos/technomancy/leiningen/issues/1956/events","html_url":"https://github.com/technomancy/leiningen/issues/1956","id":101185915,"number":1956,"title":"pprint runtime info as edn","user":{"login":"laurentpetit","id":98286,"avatar_url":"https://avatars.githubusercontent.com/u/98286?v=3","gravatar_id":"","url":"https://api.github.com/users/laurentpetit","html_url":"https://github.com/laurentpetit","followers_url":"https://api.github.com/users/laurentpetit/followers","following_url":"https://api.github.com/users/laurentpetit/following{/other_user}","gists_url":"https://api.github.com/users/laurentpetit/gists{/gist_id}","starred_url":"https://api.github.com/users/laurentpetit/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/laurentpetit/subscriptions","organizations_url":"https://api.github.com/users/laurentpetit/orgs","repos_url":"https://api.github.com/users/laurentpetit/repos","events_url":"https://api.github.com/users/laurentpetit/events{/privacy}","received_events_url":"https://api.github.com/users/laurentpetit/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":2,"created_at":"2015-08-15T15:45:31Z","updated_at":"2015-08-16T03:41:15Z","closed_at":null,"body":"Counterclockwise needs to synchronize the Eclipse project classpath with leiningen so that dependencies, source dependencies, native dependencies are correctly set.\r\n\r\nAt least for 2 purposes:\r\n\r\n- leveraging as much as possible from the IDE in terms of static code introspection (suggesting java / javadoc from the listed dependencies and dependencies source jars)\r\n- easy / quick startup of a REPL with all the dependencies (including native dependencies) without involving leiningen (works well in 80% cases and is the preferred way by many because startup time is faster)\r\n\r\nCurrently, what has been suggesting for \"calling leiningen and get runtime information\" is the following ( http://librelist.com/browser//leiningen/2015/8/14/getting-leiningen-classpath/ ):\r\n\r\n```\r\nlein update-in : assoc :eval-in :pprint -- run -m clojure.main\r\n```\r\n\r\nThis works, but has at least 2 problems:\r\n\r\n- Problem 1: what is output is not readable as edn. The first part looks like\r\n        ```\r\nJava: java\r\nClasspath: -classpath /Users/laurentpetit/tmp test/tutorial/test:/Users/laurentpetit/tmp test/tutorial/src:/Users/laurentpetit/tmp test/tutorial/dev-resources:/Users/laurentpetit/tmp test/tutorial/resources:/Users/laurentpetit/tmp test/tutorial/target/classes:/Users/laurentpetit/.m2/repository/clojure-complete/clojure-complete/0.2.3/clojure-complete-0.2.3.jar:/Users/laurentpetit/.m2/repository/overtone/scsynth-extras/3.5.7.0/scsynth-extras-3.5.7.0.jar:/Users/laurentpetit/.m2/repository/net/java/dev/jna/jna/3.4.0/jna-3.4.0.jar:/Users/laurentpetit/.m2/repository/overtone/at-at/1.2.0/at-at-1.2.0.jar:/Users/laurentpetit/.m2/repository/overtone/byte-spec/0.3.1/byte-spec-0.3.1.jar:/Users/laurentpetit/.m2/repository/overtone/osc-clj/0.9.0/osc-clj-0.9.0.jar:/Users/laurentpetit/.m2/repository/overtone/libs.handlers/0.2.0/libs.handlers-0.2.0.jar:/Users/laurentpetit/.m2/repository/overtone/scsynth/3.5.7.0/scsynth-3.5.7.0.jar:/Users/laurentpetit/.m2/repository/commons-net/commons-net/3.0.1/commons-net-3.0.1.jar:/Users/laurentpetit/.m2/repository/javax/jmdns/jmdns/3.4.1/jmdns-3.4.1.jar:/Users/laurentpetit/.m2/repository/clj-glob/clj-glob/1.0.0/clj-glob-1.0.0.jar:/Users/laurentpetit/.m2/repository/org/clojure/clojure/1.6.0/clojure-1.6.0.jar:/Users/laurentpetit/.m2/repository/overtone/overtone/0.9.1/overtone-0.9.1.jar:/Users/laurentpetit/.m2/repository/overtone/midi-clj/0.5.0/midi-clj-0.5.0.jar:/Users/laurentpetit/.m2/repository/org/clojure/tools.nrepl/0.2.10/tools.nrepl-0.2.10.jar:/Users/laurentpetit/.m2/repository/org/clojure/data.json/0.2.3/data.json-0.2.3.jar:/Users/laurentpetit/.m2/repository/clj-native/clj-native/0.9.3/clj-native-0.9.3.jar\r\nJVM args: -Dfile.encoding=UTF-8 -XX:+TieredCompilation -XX:TieredStopAtLevel=1 -XX:-OmitStackTraceInFastThrow -Dclojure.compile.path=/Users/laurentpetit/tmp test/tutorial/target/classes -Dtutorial.version=0.1.0-SNAPSHOT -Dclojure.debug=false -Djava.library.path=/Users/laurentpetit/tmp test/tutorial/target/native/macosx/x86_64\r\n        ````\r\nSpot the problem? Yes, there's a space in the project directory name. Having to try to reconcile things by parsing plain text is hard to get right.\r\n\r\n- Problem 2: just an aesthetic problem, I guess. CCW doesn't care at all about the pprint form (here, `clojure.main`). It's there just to make the `:eval-in :pprint` happy so that it does not either display the hel page (if nothing provided), or do too much (most built-in leiningen tasks). It just appears that the `run -m clojure.main` task is the most innocuous one getting the runtime information in addition to the pprinted form.\r\n\r\nI have done a quick fork of leiningen which adds a `:pprint-edn` version of `:eval-in` which is similar to `:pprint` but prints a map before the form, and not plain text. I will submit the PR very soon so you can react on it. I still don't like that having this map feels like runtime information is \"second-line citizen\".\r\n"},"comment":{"url":"https://api.github.com/repos/technomancy/leiningen/issues/comments/131487532","html_url":"https://github.com/technomancy/leiningen/issues/1956#issuecomment-131487532","issue_url":"https://api.github.com/repos/technomancy/leiningen/issues/1956","id":131487532,"user":{"login":"laurentpetit","id":98286,"avatar_url":"https://avatars.githubusercontent.com/u/98286?v=3","gravatar_id":"","url":"https://api.github.com/users/laurentpetit","html_url":"https://github.com/laurentpetit","followers_url":"https://api.github.com/users/laurentpetit/followers","following_url":"https://api.github.com/users/laurentpetit/following{/other_user}","gists_url":"https://api.github.com/users/laurentpetit/gists{/gist_id}","starred_url":"https://api.github.com/users/laurentpetit/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/laurentpetit/subscriptions","organizations_url":"https://api.github.com/users/laurentpetit/orgs","repos_url":"https://api.github.com/users/laurentpetit/repos","events_url":"https://api.github.com/users/laurentpetit/events{/privacy}","received_events_url":"https://api.github.com/users/laurentpetit/received_events","type":"User","site_admin":false},"created_at":"2015-08-16T03:41:14Z","updated_at":"2015-08-16T03:41:14Z","body":"I'm not opposed to your ideas, just want to share thoughts yet:\n\nLe dimanche 16 août 2015, Phil Hagelberg <notifications@github.com> a\nécrit :\n\n> > I still don't like that having this map feels like runtime information\n> is \"second-line citizen\".\n>\n> Emitting two forms is a bit strange. What if the first map were emitted as\n> metadata on the code form instead?\n\n\nI haven't thought too much about the fact that the second form is\nguaranteed to be read-able in all cases. Will there be some times where it\nwouldn't read if some tag reader is not installed in the reading jvm?\nHaving 2 forms guarantees that the first read will always only get runtime\ninfo and not the command.\n\n>\n> I could see an argument for doing this in the existing :pprint instead of\n> adding a new defmethod; essentially it is turning something that was\n> originally only designed for human consumption into a form that is both\n> human-readable and machine-readable.\n\n\nThe refactoring in my PR duplicates almost no code. The edn version takes a\nlot more spaces and visual clutter for the human reading.\nAlso, if one wants to start enhancing the edn version with relevant but yet\nmissing information, making human (more concise, not necessarily exhaustive\nsummary) and edn version the same output will always bring necessary\ncompromises to the design choice.\n\nFor instance there are other requirements coming, I didn't want to bring\neverything to the table in one pass: source jars. I don't known if their\nresolution should be done in this :pprint call. It could totally be done in\nanother new task. I have no strong idea about it yet.\n\nAnother thought while we're at it: there would be an argument to have\neverything related to aether (jar dependencies, source dependencies) be\noutput to stdout as top level forms each: aether generally takes a long\ntime to process, and being able, in the consuming side, to read classpath\nelements as they come, without having to wait for the whole internet to be\ndownloaded could enhance the user experience.\nEdn explicitly makes this possible over xml. Thus the :pprint-edn would\nbecome something like\n{:java-args \"....\"}\n{:classpath-arg [\"one classpath element\"]}\n{:classpath-arg [\"second classpath element\"]}\nThe end would be marked just by closing of the stream. So someone just\nwanting the whole info at once could just merge the top level forms with\nconj\nI understand this would be more work since it would probably require\nimplementing additional listener hooks into aether/pomegranate.\nJust talking about it right now because it should probably be a design\nchoice of the :pprint-edn to be made early if we don't want to break things\nlater.\n\n>\n> The only question is whether there are any existing automated tools which\n> rely on the current ad-hoc jvm args printing. Seems unlikely but possible.\n\n\nI can start asking the usual suspect about it and also try a github search\nthough it may return a lot of false positives.\n\n\n> —\n> Reply to this email directly or view it on GitHub\n> <https://github.com/technomancy/leiningen/issues/1956#issuecomment-131481305>\n> .\n>\n\n\n-- \nLaurent Petit\n"}}