Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve the order in which ns-tracker returns the namespaces #29

Open
frankitox opened this issue Mar 29, 2022 · 2 comments
Open

Improve the order in which ns-tracker returns the namespaces #29

frankitox opened this issue Mar 29, 2022 · 2 comments

Comments

@frankitox
Copy link

Hi! I'm using this library because pedestal uses it to reload the files.

The problem is that ns-tracker doesn't return the namespaces in the order in which each file depends on the other (by depending I mean the :require at the top ns declaration). For example, if I have 3 files:

(ns first)

(def f 1)
(ns second
  (:require [first]))

(def s (+ 2 first/f))
(ns third
  (:require [second]))

(def t second/s)

Now, using ns-tracker:

(def t (ns-tracker ["src"]))

;; after editing and saving `first.clj` I do:

(t)
;; => (first third second)

Let's say that I changed first/f to 30, the problem is that if I reload them in that order, then third/d will have the older value:

(require 'first :reload)
(require 'third :reload)
(require 'second :reload)
first/f ;; => 30
second/s ;; => 32
third/t ;; => 3

Now, I wanted to ask, is this expected or it is a bug?

@frankitox frankitox changed the title Improve the order in which ns-tracker return the namespaces Improve the order in which ns-tracker returns the namespaces Mar 29, 2022
@stefan-toubia
Copy link

Also ran into this issue, fixed it in this fork liftoffio@d016c78

@weavejester
Copy link
Owner

This issue slipped through the cracks of my inbox the first time around. This does appear to be a bug, and I'd accept a PR to fix it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants