halostatue
I’m using some asynchronous linting plug-ins for Vim8 and I’m finding myself annoyed by the fact that they compile to _build/ which breaks Phoenix reload, etc. I found this comment by José:
It is best if editors run their commands on a separate _build directory. It that is not easily doable today, let’s find a way to make it so.
The only way that I can see that this might work right now is if I modify my mix.exs so that the project build_path is something like System.get_env("EDITOR_MIX_BUILD_PATH", "build_path") and remembering to set (either directly or through something like direnv) the EDITOR_MIX_BUILD_PATH variable to something like .vim_build instead of _build.
Is there any other way to do this (e.g., mix compile --build-path .vim_build), because the Vim plug-ins I’m using aren’t really using the mix configuration except the build tools.
I’m currently using Neomake for those interested. It’s similar to Ale, but Ale’s linter policy—run everything by default—combined with a stated non-desire to make it easy to find out what linters are available and active, means that if you have dialixir installed, your computer will be brought to its knees with twenty instances of mix dialyzer. Neomake doesn’t currently have a dialixir plug-in, but it offers a relatively simple way to discover what’s available (neomake#ft#makers#elixir#EnabledMakers()) and then remove the ones you don’t want. (If a dialyzer plug-in does show up, I’m going to argue very heavily that it should not be enabled by default—and that it should explicitly be opt-in.)
Where Next?
Trending in Questions
Other Trending Topics
Latest on Elixir Forum
Sponsor Spotlight
Bringing learning, work and compliance together since 1987.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #blog-post
- #phoenix_html
- #iex
- #graphql
- #ai
- #genstage
- #elixirconf-us
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #metaprogramming
- #security
- #hex
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Develop your skills with books, videos, and courses.
Producing high quality Elixir screencasts since 2017.
Enabling companies to succeed by building software people love.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Marked As Solved- Show Best Posts
- Show All Posts (oldest first)
- Show All Posts (newest first)
halostatue
For anyone who is looking for this later: this has been fixed in Elixir 1.9 or later with the introduction of
MIX_BUILD_PATH. There is a pending fix in Elixir 1.10 that ensures that theMIX_BUILD_PATHstill has the environment appended. See PR#9189.NOTE: I found my post here while looking for something else, because I want to be able to add the Elixir and/or Erlang version to the build path, and the apparent recommendation is to set the
env_path, not thebuild_path. This will make it possible for me to build the same application under multiple versions of Elixir so that I can test newer versions before I want to upgrade or during development. I have to test this, but I think that I will be settingenv_pathto be something likePathname.join(["_build", System.version()]).