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

clean-ns: fall back to :relative-path, when given #251

Conversation

plexus
Copy link
Contributor

@plexus plexus commented Apr 18, 2019

Allow the client to send both the absolute path and a relative path to a file,
we use the first one that we can find.

The absolute path is used when the client (Emacs) and the JVM are on the same
filesystem/same machine. The second is used when they are not on the same
filesystem (e.g. running nREPL on a remote machine or in a VM), but the JVM runs
in the (mounted) project directory, so that relative file lookups still work.

I failed to run the tests locally. Will see what CI says.

See clojure-emacs/clj-refactor.el#380 (comment)

Allow the client to send both the absolute path and a relative path to a file,
we use the first one that we can find.

The absolute path is used when the client (Emacs) and the JVM are on the same
filesystem/same machine. The second is used when they are not on the same
filesystem (e.g. running nREPL on a remote machine or in a VM), but the JVM runs
in the (mounted) project directory, so that relative file lookups still work.

See clojure-emacs/clj-refactor.el#380 (comment)
plexus added a commit to plexus/clj-refactor.el that referenced this pull request Apr 18, 2019
This makes use of a change to refactor-nrepl [1], but should be safe when
using older versions of refactor-nrepl, as in that case it simply uses the
absolute path, which is generally preferred over the relative one.

When used with the change to refactor-nrepl it will try first the absolute, then
the relative path, and use the first that can be found.

[1]: clojure-emacs/refactor-nrepl#251
plexus added a commit to clojure-emacs/clj-refactor.el that referenced this pull request Apr 18, 2019
This makes use of a change to refactor-nrepl [1], but should be safe when
using older versions of refactor-nrepl, as in that case it simply uses the
absolute path, which is generally preferred over the relative one.

When used with the change to refactor-nrepl it will try first the absolute, then
the relative path, and use the first that can be found.

[1]: clojure-emacs/refactor-nrepl#251
@plexus
Copy link
Contributor Author

plexus commented Apr 19, 2019

FAIL in (sanity) (form-init5821700100748902327.clj:67)
errors handled properly
expected: (string? (:err response))
  actual: (not (string? nil))

This seems unrelated, is this a flaky test?

Copy link
Member

@expez expez left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me.

We also need an update to the readme for the clean-ns op and a changelog entry 👍

(defn clean-ns [{:keys [path relative-path]}]
{:pre [(seq path) (string? path)]}
;; Try first the absolute, then the relative path
(let [path (first (filter #(some-> % io/file .exists) [path relative-path]))]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

some might be better here since we're looking for the first thing that fulfills some pred

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since the predicate returns boolean rather than the truthy value I find it awkward to use some for such cases, as you end up with (some #(and (pred? %) %) coll). Would you still prefer some?

@plexus plexus merged commit d56ff99 into clojure-emacs:master Apr 22, 2019
@plexus
Copy link
Contributor Author

plexus commented Apr 22, 2019

I've updated the CHANGELOG and README, and rewrote that use of first + filter.

It's very annoying that I can't run tests locally, no matter what I do I get

clojure.lang.LispReader$ReaderException: java.lang.RuntimeException: No reader function for tag Inf

when mranderson loads the ns parallel.core. I've tried forcing the Clojure version to 1.10 but nothing seems to work.

@plexus
Copy link
Contributor Author

plexus commented Apr 22, 2019

I'm very sorry, I accidentally pushed this to master, and I can't rewind because master is protected. I hope this looks good! I'll try to do some better testing to make sure, let me know if you think this needs more work @expez and I'll do it on a new PR.

@expez
Copy link
Member

expez commented Apr 23, 2019

I tried grepping the project for ##Inf but I can't find anything extending the reader to understand that tag. There's also no messing around with *default-data-reader-fn* AFAICT.

@benedekfazekas Does it make a huge difference if you use that library or can we drop it from mranderson? If not, we might consider opening an issue over at that repo to let him know that this is causing breakage over here.

@plexus
Copy link
Contributor Author

plexus commented Apr 23, 2019

Clojure itself understands ##Inf, not 100% sure when it was added, I think maybe 1.9.

It also seems to work on CI so clearly I'm doing something wrong, I just have no clue what. I'm just trying to run make test. I've tried blowing away my ~/.m2 but that didn't help.

@expez
Copy link
Member

expez commented Apr 23, 2019

Clojure itself understands ##Inf, not 100% sure when it was added, I think maybe 1.9.

Aha. Did not know that!

It also seems to work on CI so clearly I'm doing something wrong

The version of Clojure that we're using is non-deterministic, since multiple versions are specified. It's just lucky that it works on the CI server. If we added proper exclusions to our project.clj that build profile would no longer run at all, since the dep we pull in through mranderson has a hard dependency on Clojure 1.9.

@benedekfazekas
Copy link
Member

yeah aware of this new limitation of MrAnderson. however, this only means that the MrAnderson step needs to be run with lein 2.9.1 (older leiningen version may pull an older version of clojure maybe). don't think this should cause any problems downstream, or?

@benedekfazekas
Copy link
Member

ah checked the above comments properly, guessing @plexus that you use an older version of leiningen?

@plexus
Copy link
Contributor Author

plexus commented Apr 23, 2019

It would appear so, I was still on 2.8.3 apparently.

@plexus
Copy link
Contributor Author

plexus commented Apr 23, 2019

Did a lein upgrade and now it seems to work. Can't believe I didn't check that to begin with 🙈 . Thanks @benedekfazekas !

@plexus plexus deleted the clean-ns-absolute-path-with-fallback-to-relative branch April 23, 2019 14:56
@benedekfazekas
Copy link
Member

nw @plexus, happy it is solved

plexus added a commit to plexus/clj-refactor.el that referenced this pull request Apr 24, 2019
This makes use of a change to refactor-nrepl [1], but should be safe when
using older versions of refactor-nrepl, as in that case it simply uses the
absolute path, which is generally preferred over the relative one.

When used with the change to refactor-nrepl it will try first the absolute, then
the relative path, and use the first that can be found.

[1]: clojure-emacs/refactor-nrepl#251
@jonpither
Copy link

When I do a clean-ns using the latest snapshot 2.5.0-SNAPSHOT, on a project with check-out deps, I get:

cljr--get-error-value: Error in nrepl-refactor: java.lang.NullPointerException: null
 at refactor_nrepl.core$cljc_file_QMARK_.invokeStatic (core.clj:129)
    refactor_nrepl.core$cljc_file_QMARK_.invoke (core.clj:127)
    clojure.core$some_fn$sp3__8653.invoke (core.clj:7461)
    refactor_nrepl.core$source_file_QMARK_.invokeStatic (core.clj:152)
    refactor_nrepl.core$source_file_QMARK_.invoke (core.clj:146)
    refactor_nrepl.ns.clean_ns$clean_ns.invokeStatic (clean_ns.clj:44)
    refactor_nrepl.ns.clean_ns$clean_ns.invoke (clean_ns.clj:39)
    clojure.lang.Var.invoke (Var.java:384)
    refactor_nrepl.middleware$clean_ns_reply.invokeStatic (middleware.clj:134)
    refactor_nrepl.middleware$clean_ns_reply.invoke (middleware.clj:133)
    refactor_nrepl.middleware$wrap_refactor$fn__6066.invoke (middleware.clj:212)
    nrepl.middleware$wrap_conj_descriptor$fn__630.invoke (middleware.clj:16)

@jonpither
Copy link

Updated to the latest clj-refactor.el, now I get:

=> nil
cljr--get-error-value: Error in nrepl-refactor: java.lang.AssertionError: Assert failed: (instance? java.io.PushbackReader rdr)
 at clojure.tools.namespace.parse$read_ns_decl.invokeStatic (parse.clj:33)
    clojure.tools.namespace.parse$read_ns_decl.invoke (parse.clj:33)
    refactor_nrepl.core$read_ns_form.invokeStatic (core.clj:108)
    refactor_nrepl.core$read_ns_form.invoke (core.clj:105)
    refactor_nrepl.core$clj_file_QMARK_.invokeStatic (core.clj:144)
    refactor_nrepl.core$clj_file_QMARK_.invoke (core.clj:139)
    clojure.core$some_fn$sp3__8653.invoke (core.clj:7461)
    refactor_nrepl.core$source_file_QMARK_.invokeStatic (core.clj:152)
    refactor_nrepl.core$source_file_QMARK_.invoke (core.clj:146)
    refactor_nrepl.ns.clean_ns$clean_ns.invokeStatic (clean_ns.clj:44)
    refactor_nrepl.ns.clean_ns$clean_ns.invoke (clean_ns.clj:39)
    clojure.lang.Var.invoke (Var.java:384)
    refactor_nrepl.middleware$clean_ns_reply.invokeStatic (middleware.clj:134)
    refactor_nrepl.middleware$clean_ns_reply.invoke (middleware.clj:133)
    refactor_nrepl.middleware$wrap_refactor$fn__6066.invoke (middleware.clj:212)

@benedekfazekas
Copy link
Member

that is a know issue with latest snapshot (not really related to this issue) i still have not got around to check. sorry.

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

Successfully merging this pull request may close these issues.

4 participants