I am not able to create my Phoenix project. Would love some advice on how to fix it.
Setup details:
Ubuntu 16.04.4 LTS
Erlang/OTP 21 [erts-10.1] [source] [64-bit]
[smp:1:1] [ds:1:1:10] [async-threads:1] [hipe]
Elixir 1.7.3 (compiled
with Erlang/OTP 20)
Mix 1.7.3 (compiled with Erlang/OTP 20)
Ecto v3.0.0
I am following the Phoenix Up and Running to make an app.
mix phx.new hello
cd hello
mix ecto.create
last command gives me:
== Compilation error in file lib/hello/repo.ex ==
** (ArgumentError) adapter Ecto.Adapters.Postgres was not compiled, ensure it is correct and it is included as a project dependency
lib/ecto/repo/supervisor.ex:71: Ecto.Repo.Supervisor.compile_config/2
lib/hello/repo.ex:2: (module)
(stdlib) erl_eval.erl:680: :erl_eval.do_apply/6
(elixir) lib/kernel/parallel_compiler.ex:206: anonymous fn/4 in Kernel.ParallelCompiler.spawn_workers/6
I have postgres installed. I have postgres super user.
Starting with Ecto 3.0, Ecto.Adapters.Postgres is not shipped with Ecto by default, therefore you have to add ecto_sql to the Mixfile dependencies:
###########
# mix.exs #
###########
defp deps do
[
# (...)
{:ecto_sql, "~> 3.0-rc.1"},
{:postgrex, ">= 0.0.0"}
]
end
# Feeling skittish about dependencies,
# I usually do this instead of simply
# doing `mix deps.get`:
$ mix deps.clean --all
$ mix do deps.get, compile
(The Ecto github repo v3.0.0 tree recommends {:ecto_sql, "~> 3.0"}, but the latest release is the 3.0.0-rc.1) therefore it won't work as of now. Interestingly there is no 3.0.0-rc.1 tag in the repo, but the documentation already refers to that and it also works with mix.)
...or, as Yufrend recommends in his answer, if you are starting a new Phoenix project, use < 1.4.0 packages.
See José Valim's “A sneak peek at Ecto 3.0” series where the first post explains the breaking changes in Ecto 3.0:
Split Ecto into ecto and ecto_sql
Ecto 3.0 will be broken in two repositories: ecto and ecto_sql.
Since Ecto 2.0, an increased number of developers and teams have been
using Ecto for data mapping and validation, without a need for a
database. However, adding Ecto to your application would still bring a
lot of the SQL baggage, such as adapters, sandboxes and migrations,
which many considered to be a mixed message.
In Ecto 3.0, we will move all of the SQL adapters to a separate
repository and Ecto will focus on the four building blocks: schemas,
changesets, queries and repos. You can see the discussion in the
issues tracker.
If you are using Ecto with a SQL database, migrating to Ecto 3.0 will
be very straight-forward. Instead of:
{:ecto, "~> 2.2"}
You should list:
{:ecto_sql, "~> 3.0"}
And if you are using Ecto only for data manipulation but with no
database access, then it is just a matter of bumping its version.
That’s it!
UPDATE
For some reason, I also needed to add {:plug_cowboy, "~> 1.0"} to the Mixfile dependencies when updating a Phoenix 1.3 project and it all started working.
Do you have phoenix_ecto 3.5.0 in your dependencies? Downgrading to 3.4.0 worked for me as a temporary fix until I figure out the underlying issue.
To force a downgrade:
Run mix deps.clean --all
Delete your mix.lock file
Update your mix.exs file limiting the phoenix_ecto version. Find the appropriate line and replace with:
{:phoenix_ecto, ">= 3.2.0 and < 3.5.0"},
Run mix deps.get
Alternatively, if you are just starting with Phoenix, you could use version 1.4 to learn, which will be released soon and does not have this issue.
First remove your current local Phoenix archive:
mix archive.uninstall phx_new
Then, to install the latest development version, follow the instructions in https://github.com/phoenixframework/phoenix/blob/master/installer/README.md
Installing the new phoenix version worked for me.
Uninstall old version:
mix archive.uninstall phx_new
Install new version:
mix archive.install hex phx_new 1.4.0-rc.2
New Projects
For creating new projects with Ecto 3.0, it's highly recommended you upgrade to the new phoenix 1.4.x installer:
$ mix archive.uninstall phx_new
$ mix archive.install hex phx_new 1.4.0-rc.2
Existing Projects
To upgrade your existing Phoenix 1.3.x projects to 1.4, read the Official Upgrade Guide and the accompanying announcement.
TLDR is that Ecto has been broken into sub-packages, and you need to specify them explicitly:
Remove your explicit :ecto dependency and update your :phoenix_ecto and :ecto_sql dependencies with the following versions:
{:ecto_sql, "~> 3.0-rc"},
{:phoenix_ecto, "~> 4.0"},
Related
We have a distributed subsystem consisting of multiple components, each component is deployed in it's own RPM package onto various different RHEL/CentOS environments. For example the components might be called:
JL_batman,
JL_superman, and
JL_wonderwoman.
And they are deployed as follows:
host1:
JL_batman
JL_wonderwoman
host2:
JL_superman
We do periodic system releases and also maintenance releases. So the initial few System Releases might look like this:
SR1:
JL_batman-1.0-hg123.rpm
JL_superman-2.7-hg651.rpm
JL_wonderwoman-1.1-hg101.rpm
SR2:
JL_batman-2.0-hg137.rpm
JL_superman-2.7-hg651.rpm
JL_wonderwoman-1.1-hg101.rpm
SR3:
JL_batman-2.0-hg137.rpm
JL_superman-2.8-hg655.rpm
JL_wonderwoman-1.1-hg101.rpm
So in each System Release not all packages are updated. Currently we use symbolic links on the YUM repo for the packages that are not updated between releases:
SR1:
JL_batman-1.0-hg123.rpm
JL_superman-2.7-hg651.rpm
JL_wonderwoman-1.1-hg101.rpm
SR2:
JL_batman-2.0-hg137.rpm
JL_superman-2.7-hg651.rpm --> ../SR1/superman-2.7-hg651.rpm
JL_wonderwoman-1.1-hg101.rpm --> ..SR1/wonderwoman-1.1-hg101.rpm
SR3:
JL_batman-2.0-hg137.rpm --> ../SR2/batman-2.0-hg137.rpm
JL_superman-2.8-hg655.rpm
JL_wonderwoman-1.1-hg101.rpm --> ..SR1/wonderwoman-1.1-hg101.rpm
Each release directory (SR1, SR2, SR3, ...) is a YUM repository. We also use symlinks to link to the following rolling repositories:
JL-old-stable --> SR1
JL-stable --> SR2
JL-testing --> SR3
This is all managed on the YUM repo server using some home grown scripts to pull packages from Jenkins and put them into the JL-testing repo (replacing any old versions there). When SR3 testing is complete and it is promoted to stable, we jiggle the symlinks as follows:
JL-old-stable --> SR2
JL-stable --> SR3
JL-testing --> SR4
Each production environment has the yum .repo file installed for JL-old-stable.repo and JL-stable.repo. Test environments also have a JL-testing.repo file. Then yum upgrade 'JL_*' is used on each environment to keep it up to date. Works OK but has some issues, mainly:
When SR3 is promoted to stable, but we need to rollback to SR2 we need to use something like yum --disablerepo='JL-*' --enablerepo='JL-old-stable' downgrade 'JL-*'.
There is no way to easily rollback from SR3 (stable) to SR1 apart from installing a new JL-SR1.repo file and then using yum --disablerepo='JL-*' --enablerepo='JL-SR1' downgrade 'JL-*'.
Is there a better way?
I would instead use a single RPM that provides no files, but Requires the various other packages with exact versioning. The "Version" of each of the config RPMs is just the release number.
OurConfig_SR_1.noarch requires:
JL_batman = 1.0
JL_superman = 2.7
JL_wonderwoman = 1.1
OurConfig_SR_2.noarch requires:
JL_batman = 2.0
JL_superman = 2.7
JL_wonderwoman = 1.1
Then you can have them all in a single repo and versionlock the OurConfig on the machine until you're ready to move it. A quick check with rpm -qi OurConfig can tell you what that system expects. Requiring the exact versions should stop an SR1 system from automatically upgrading JL_batman to 2.0 (I didn't test this of course!).
I am trying to install the MongoDB swift driver using the swift package driver. I followed their instructions and installed the mongo-c-driver using home-brew. I then created a new directory and within a new project using:
swift package init --type executable
I then added the dependencies to the Package.swift file.
When trying to run any command that summonsswift package resole in the directory, i get the following error:
error: the package PackageReference(identity: "mongo-swift-driver", name: nil, path: "https://github.com/mongodb/mongo-swift-driver.git", isLocal: false) # 0.0.2 contains revisioned dependencies:
PackageReference(identity: "swift-bson", name: nil, path: "https://github.com/mongodb/swift-bson", isLocal: false) # master
PackageReference(identity: "swift-mongoc", name: nil, path: "https://github.com/mongodb/swift-mongoc", isLocal: false) # master
I made sure that everything is up to date and that the first line of the Package.swift is // swift-tools-version:4.0
I would like to know what these revisioned dependencies are, as i have not found anything useful. And how this error can be resolved.
The Swift Evolution proposal that introduced the ability to specify branches instead of revisions in SPM packages (SE-0150 says this:
While this feature [specifying branches] is useful during development, a package's dependencies should be updated to point at versions instead of branches before that package is tagged for release. This is because a released package should provide a stable specification of its dependencies, and not break when a branch changes over time. To enforce this, it is an error if a package referenced by a version-based dependency specifies a branch in any of its dependencies.
It looks like the version 0.0.2 of the parent package that you're using did not follow the rule to switch to specific versions for its dependencies and SPM doesn't allow this.
If possible, you should try to use a newer version of the parent package that fixes this issue. If a newer version doesn't exist, you may have to override the dependency and fix it yourself (I believe you can use swift package edit to do that — or fork the dependency and point to your own repo, of course.)
I'm new to Purescript and am following the tutorial for installation. Purescript itself is working and I can start the CLI using pulp psci, but installing purescript-list runs into trouble.
Having entered the command bower install purescript-lists --save, I get a long list of package names, but when it gets to purescript-eff and purescript-prelude I run into some version conflicts:
bower purescript-eff#^2.0.0 cached https://github.com/purescript/purescript-eff.git#2.0.0
bower purescript-eff#^2.0.0 validate 2.0.0 against https://github.com/purescript/purescript-eff.git#^2.0.0
Unable to find a suitable version for purescript-eff, please choose one by typing one of the numbers below:
1) purescript-eff#^1.0.0 which resolved to 1.0.0 and is required by purescript-console#1.0.0
2) purescript-eff#^2.0.0 which resolved to 2.0.0 and is required by purescript-st#2.0.0
Prefix the choice with ! to persist it to bower.json
? Answer
A similar message is shown for purescript-prelude. No matter which options I choose, both pulp build and pulp run fail with:
$ pulp build
* Building project in /Developer/purescript/training1
Error found:
in module PSCI.Support
at /Developer/purescript/training1/bower_components/purescript-psci-support/src/PSCI/Support.purs line 10, column 34 - line 10, column 53
Cannot import value unsafeInterleaveEff from module Control.Monad.Eff.Unsafe
It either does not exist or the module does not export it.
See https://github.com/purescript/purescript/wiki/Error-Code-UnknownImport for more information,
or to contribute content related to this error.
Compiling PSCI.Support
* ERROR: Subcommand terminated with exit code 1
What have I missed here?
Thanks
Chris W
If you are using psc version 0.10.* you should go with prelude, lists and eff v2*.
If you are using psc version 0.9.* you should go with prelude, lists and eff v1*.
If you are using psc 0.10.* you might want to update pulp to version 9.1.0
The problem occurs due to breaking changes between psc 0.9 and 0.10 and the relevant libraries. by writing bower install purescript-lists --save you are asking bower for the latest dependencies which conflict with the dependency versions specified in your bower.json.
I'm using aldeed:autoform#5. I also want to use yogiben's autoform-file, but I had trouble getting that to work with autoform#5 so I've used a fork by abdj:autoform-file.
Now I want to use yogiben:admin. According to the discussion on github and the latest master (https://github.com/yogiben/meteor-admin/blob/master/package.js), yogiben:admin#1.1.0 uses aldeed:autoform#4.2.2 || 5.0.0.
So why do I get this error?
C:\Webdev\koolaid>meteor add yogiben:admin#1.1.0
=> Errors while adding packages:
While selecting package versions:
error: Conflict: Constraint aldeed:autoform#4.2.2 is not satisfied by aldeed:autoform 5.1.2.
Constraints on package "aldeed:autoform":
* aldeed:autoform#5.0.2 <- abdj:autoform-file 0.2.0
* aldeed:autoform#4.2.2 <- yogiben:admin 1.1.0
Looks to me like Meteor is somehow picking up the wrong version from github? BTW I'm using Meteor WindowsPREVIEW#0.3.0.
How do I get all these packages to play nice together?
On Debian/squeeze in /usr/lib I have:
/usr/lib/libboost_python-py25.so /usr/lib/libboost_python-py26.so
I'm trying to build
/usr/lib/libboost_python-py27.so
to go with a pythonbrewed version of python 2.7 by specifying --buildID=py27. But bjam keeps generating only
libboost_python.so.1.42.0
and then a link to
libboost_python.so
How do I get bjam and the Jamroot of boost to give me an appropriately named .so? I'm guessing the package maintainers managed to do it......
The command lines I have tried are:
bjam --layout=tagged --buildID=py27 --with-python
bjam --buildID=py27 --with-python
At least with the latest Boost version you should be able to do:
b2 --python-buildid=py27 --with-python
But if you must use 1.42 the syntax would be:
bjam --buildid=py27 --with-python
In other words.. The options are in lower case and are case sensitive.