[go: up one dir, main page]
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.

Sign up for GitHub

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

Jump to bottom

eastwood is confused by source-paths starting with "./" #66

Closed
philandstuff opened this issue May 7, 2014 · 3 comments
Closed

eastwood is confused by source-paths starting with "./" #66

philandstuff opened this issue May 7, 2014 · 3 comments

Comments

@philandstuff
Copy link

We use Stuart Sierra's "clojure reloaded" flow, and with it our :dev profile contains an extra source path:

  :profiles { :dev {:source-paths ["./dev"]}}

The dev directory contains one file, user.clj, which defines the namespace user.

However, if I run lein eastwood with this in my project.clj, I get this output:

The following file(s) contain ns forms with namespaces that do not correspond
with their file names:
Directory: /Users/philandstuff/<project>/./dev
    File                 : /Users/philandstuff/<project>/dev/user.clj
    has namespace        : user
    should have namespace: .Users.philandstuff.<project>.dev.user
    or should be in file : user.clj

No other linting checks will be performed until these problems have
been corrected.

The 'should have namespace' and 'should be in file' messages above are
merely suggestions.  It may be better in your case to rename both the
file and namespace to avoid name collisions.
Subprocess failed

In other words, eastwood is confused about the namespace that ./dev/user.clj should live in.

Changing the project.clj entry to this instead fixes it:

  :profiles { :dev {:source-paths ["dev"]}}

(ie removing the leading ./ from the :source-paths)

The dependency I'm using is [jonase/eastwood "0.1.2"].
@jafingerhut
Copy link
Collaborator

Thanks for the report. I've implemented and done a quick spot check on what I think is a fix for this. Glad to see there is an easy workaround for this, but nice if Eastwood can avoid the user needing to know about this.

@jafingerhut
Copy link
Collaborator

philandstuff, Eastwood version 0.1.3 was released today. It includes a fix for this issue. Please try it out and let us know whether it solves this issue. Thanks.

@philandstuff
Copy link
Author

@jafingerhut yup, works great. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@jafingerhut @philandstuff