BarelyFunctional

Mix phx.new and phoenix.new error in FreeBSD

Just went to create the first app on a freebsd 11 digitalocean droplet and:

mix phx.new

and

mix phoenix.new

both give an error like:

* creating myapp/config/config.exs
** (File.Error) could not make directory (with -p) "myapp/config": no such file or directory
    (elixir) lib/file.ex:208: File.mkdir_p!/1
    (mix) lib/mix/generator.ex:29: Mix.Generator.create_file/3
    lib/phoenix_new.ex:545: anonymous fn/5 in Mix.Tasks.Phoenix.New.copy_from/3
    (elixir) lib/enum.ex:1755: Enum."-reduce/3-lists^foldl/2-0-"/3
    lib/phoenix_new.ex:532: Mix.Tasks.Phoenix.New.copy_from/3
    lib/phoenix_new.ex:233: Mix.Tasks.Phoenix.New.run/4
    (mix) lib/mix/task.ex:294: Mix.Task.run_task/3
    (mix) lib/mix/cli.ex:58: Mix.CLI.run_task/2

That’s as the default freebsd user that is created when a droplet is created.

If I su to root, this is the result:

** (Mix) The task "phoenix.new" could not be found

Have I installed elixir/erlang as the wrong user?

Is this a permissions related error?

I had this before upgrading to 1.3. Is it normal to see both mix phoenix.new and mix phx.new after upgrading and running:

mix --help

mix phoenix.new       # Creates a new Phoenix v1.2.4 application
mix phx.new           # Creates a new Phoenix v1.3.0-rc.2 application using the experimental generators

Thanks

11 comments

/phoenix #mix #errors #freebsd

1 4290 11

2017-07-01 03:10:35 UTC

Marked As Solved

BrightEyesDavid

As @NobbZ described, other group members don’t have write access to the ‘www’ directory due to the second digit of 755 being 5 and not 7.

Assuming you want to go ahead with creating the new project on the droplet, and you won’t be serving the entire /usr/local/www over the web, how about something like:

$ su
# cd /usr/local/www
# mkdir my_projects
# chown freebsd:freebsd my_projects
# exit
$ cd /usr/local/www/my_projects
$ mix phx.new project_a

Or just put the project directory somewhere in freebsd’s home directory?

Post #7

Also Liked

NobbZ

When you su root you will probably don’t have the phoenix-archive in roots ~/.mix, you will need to reinstall the archive as root (which is not what I’d recommend).

Usually you do not even need to have the generators at all when deploying to a host, they are only meant to be used for development.

Just build a release, push it to your host and run it.

If though, you wan’t to use that machine as build and stage server, there is still no need to have the generators available. Just check out from source control and cd into the source folder and run the usual test and compile tasks after doing mix deps.get.

Post #2

NobbZ

If he wants to stick to developing on that droplet at all, he should definitively go with $HOME.

I do not think that any user that has a homedir below /home should do anything outside of it.

Post #8

NobbZ

OK, I du understand the desire to not develop locally in your case and as well accept it as an hard requirement, still you could dual boot your own machine and also work during bus times.

Still lets talk about phoenix on your droplet:

Since you want to develop and host on that machine, I’d develop as the default user in its $HOME, you could even use SSHFS to blend the remote stuff into your own filesystem and use your local editors and stuff. Depending on your network speed it might be slow though and there might be other remote FS available which suite you better.

That development phoenix can listen on a port only known to you, something random. Delivered directly, without a reverseproxy or stuff. But shut it down after you have finished your development session.

Track your development in git, hg, or darcs (or any other DVCS) and push into a well known upstream repository hoster which allows you to have private repositories, this is meant as a back up strategy primarily, later on you will learn all the other usefullness after you have used it a while.

Whenever you have achieved something that you want to publish, just build a release, push it into the appropriate folder (often /usr/local/bin for non-upstream-repository-software) and create a systemd unit to start it (well, or a script for whichever init system you use).

You can name the user used for running the phoenix stuff however you want it to, but I’d name it either $your_app_name, phoenix, or www, this way you can easily see what that user was created for.

Also I’m not sure if I had created a freeBSD droplet, since freeBSD is known to be special. I had choosen either a Debian, Ubuntu, or your schools distro. The first two have great communities and you will find help online. The last one should be that one which you feel comfortable with and which you can get support for in your university. Were you can grab a friend and ask, or a professor, or even your universities unix sys-op.

Please ignore my last paragraph when your school uses and teaches freeBSD