Clojurians Log v2

finally back in the office

time to get some stuff done :simple_smile:

Nice, looking forward to it

I still have a couple layers to push out of my .proton

go for it!

@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

Thanks for the heads up

@dvcrn: how happy are you with how we implemented the linter system?

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

Hmm that’s odd.

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

moving register-layer-depenencies into init should fix this. Let me try

So do you have all the julia packages too? (question only makes sense if you don’t have the layer enabled, obviously)

the bug is with the implementation of (register-layer-dependencies

(register-layer-dependencies :tools/linter [:linter-clojure])

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

I thought it was kinda backwards there

I mean -

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

So we kinda have a design question here

In the clojure layer we have a linter package

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

Is that the behavior you want?

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

That’s probably right, but I don’t love the solution

What’s the issue with having register-layer-dependencies be a multimethod just like the rest of the config methods?

hmm

you mean like register-layer-dependencies :lang/clojure :tools/linter [:linter-clojure]?

could work

That is kinda how I imagined it

In general, I think we should think a bit more about code structure

(I'm guilty of that too)

The lang/clojure layer depends on the tools/linter layer for linting support — if the user wants both, then install the linter-clojure package

Otherwise don't

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

I think we need a batter framework for disabling / enabling stuff dynamically

Really really don't like it the way we are doing it right now

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)))))

I had to rm ~/.atom/config.cson 3 times today because things got wacky

So I agree, it would be great to come up with something better

most settings should be completely stateless because we kill them anyway on start

just this damn disabledPackages

grrrrr

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)?

we do that, just not the packages

because we had the problem that things got jumpy

like it deactivates and activates in too close time and then calls get ignored

so even though atom thinks tab-bar is disabled, it is not

Yeah… hmm. Is there anything we can hack on from the outside, or should we start looking at changes to core atom packages

we just need to make sure that disable-package can't multiple times disable something

so if linter-jshint is off, it will not get added to disabledPackages again

It probably isn’t as simple as reading in the config array, calling distinct, and writing it out again is it?

that's what I thought I did 😐

(defn is-activated? [package-name]
  (let [package-names (->> (.getActivePackages packages) js->clj (map #(.-name %)))
        filtered-packages (filter #(= package-name %) package-names)]
    (> (count filtered-packages) 0)))

ah wait, I misread