This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-01-05
Channels
- # admin-announcements (183)
- # aws (30)
- # beginners (22)
- # boot (301)
- # cider (19)
- # cljs-dev (3)
- # cljsrn (23)
- # clojars (15)
- # clojure (136)
- # clojure-italy (8)
- # clojure-nl (4)
- # clojure-russia (19)
- # clojured (10)
- # clojurescript (134)
- # component (48)
- # cursive (7)
- # datavis (4)
- # datomic (50)
- # devcards (6)
- # events (9)
- # jobs (1)
- # ldnclj (10)
- # lein-figwheel (19)
- # leiningen (1)
- # luminus (16)
- # off-topic (5)
- # om (151)
- # proton (60)
- # re-frame (10)
- # reagent (25)
- # remote-jobs (1)
- # slack-help (3)
- # spacemacs (1)
- # vim (1)
@geksilla, @sglyon I pushed some changes that disable debug messages by default. Go into proton/config/proton.cljs and just set debug to true to get it back
I think in general the 'optional package' system (layers enabling / disabling packages) is not good yet
I also noticed that proton installed javascript linters for me even though I don't use the js layer
Actually now that I think of it I saw that too — I just assumed I had the javascript layer on
yeah it seems like there is no check if the actual layer is enabled. It just pulls in all dependencies
So do you have all the julia packages too? (question only makes sense if you don’t have the layer enabled, obviously)
there is no way the package manager can filter based on this information that :linter-clojure
should only get installed when the clojure layer is on
To me I would think that we’d have some method a layer can implement that specifies other layers as dependencies
when tools/linter is on, install linter-clojure but not: when tools/linter is on, AND clojure is on, install linter-clojure
What you described above sounds to me like this package (clojure linting) will only work properly if BOTH tools/linter and lang/clojure are enabled
well, the difference here is that register-layer-depenencies
modifies state the moment it gets called.
the other ones are multimethods that get called when core does it's thing.
Moving the register-layer-dependencies
call into init
fixes this because it will not modify the state if init
didn't get called which it only will when the layer is enabled.
Might be a bit hacky though
What’s the issue with having register-layer-dependencies
be a multimethod just like the rest of the config methods?
you mean like register-layer-dependencies :lang/clojure :tools/linter [:linter-clojure]
?
The lang/clojure layer depends on the tools/linter layer for linting support — if the user wants both, then install the linter-clojure package
BTW, moving the register-layer-dependencies
call into init-layer
worked just how you thought
The javascript linters were only installed when both the lang/javascript and tools/linter layers were enabled
My disabled packages look like this:
disabledPackages: [
"linter-jshint"
"linter-jshint"
"linter-jshint"
"linter-jshint"
"linter-jshint"
"linter-jshint"
"linter-jshint"
"linter-jshint"
"linter-jshint"
"linter-jshint"
"linter-jshint"
"linter-jshint"
"linter-jshint"
"linter-jshint"
"atom-ternjs"
"javascript-snippets"
"autocomplete-modules"
"docblockr"
"react"
"react-snippets"
"linter-eslint"
"linter-jshint"
]
I thought that might have solved it but apparently didn't:
(if (or (is-activated? package-name) force)
(do
(helpers/console! (str "disabling package " package-name))
(.disablePackage packages package-name)))))
So the reason we can’t just completely wipe config.cson when proton starts is we try to remember things like toggles (disabled tabs, status bar, etc)?
Yeah… hmm. Is there anything we can hack on from the outside, or should we start looking at changes to core atom packages
It probably isn’t as simple as reading in the config array, calling distinct
, and writing it out again is it?