I get the following error when I attempt to install/add fxcmpy and make it work with Flask framework. Any suggestions are appreciated.
Using version ^1.2.10 for fxcmpy
Updating dependencies
Resolving dependencies...
SolverProblemError
Because no versions of fxcmpy match >1.2.10,<2.0.0
and fxcmpy (1.2.10) depends on python-socketio (4.4), fxcmpy (>=1.2.10,<2.0.0) requires python-socketio (4.4).
And because flask-socketio (5.1.1) depends on python-socketio (>=5.0.2)
and no versions of flask-socketio match >5.1.1,<6.0.0, fxcmpy (>=1.2.10,<2.0.0) is incompatible with Flask-SocketIO (>=5.1.1,<6.0.0).
So, because repl-python3-flask depends on both Flask-SocketIO (^5.1.1) and fxcmpy (^1.2.10), version solving failed.
at /opt/virtualenvs/python3/lib/python3.8/site-packages/poetry/puzzle/solver.py:241 in _solve
237│ packages = result.packages
238│ except OverrideNeeded as e:
239│ return self.solve_in_compatibility_mode(e.overrides, use_latest=use_latest)
240│ except SolveFailure as e:
→ 241│ raise SolverProblemError(e)
242│
243│ results = dict(
244│ depth_first_search(
245│ PackageNode(self._package, packages), aggregate_package_nodes
Related
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"},
I have a ASP.NET WebForms application that uses some Ninject packages, but I am stuck at a certain version. When I try to upgrade to the latest version, I get "Unable to resolve dependencies" issues.
The packages in question are:
Package InstalledVer LatestVer
------------------------------------------------------
Ninject v3.2.2 v3.3.4
Ninject.Web v3.2.1 ✔ v3.2.1
Ninject.Web.Common v3.2.3 v3.3.1
Ninject.Web.Common.WebHost v3.2.3 v3.3.1
If I try updating Ninject, I get:
Unable to resolve dependencies. 'Ninject 3.3.4' is not compatible with
'Ninject.Web 3.2.1 constraint: Ninject (>= 3.2.0 && < 3.3.0)'
but Ninject.Web is already at the latest version!
Should I change the Dependency behaviour of Ninject.Web or would this be unsafe? If I do, what should I change the Dependency behavior to?
Thanks
Okay, so this is how to fix:
Remove the Ninject.Web package completely. This package is no longer required as it is now integrated into Ninject.Web.Common (well, version v3.3+ anyway)
Update the packages Ninject, Ninject.Web.Common and Ninject.Web.Common.WebHost. These should now upgrade okay. For me, they are both v3.3.1.
As part of the package upgrade a new file App_Start\Ninject.Web.Common.cs will have been added. This is just a rename of the existing App_Start\NinjectWeb.Common.cs so either [a] delete the new file or [b] migrate over your Ninject module registrations and remove the old file.
In web.config, you should now remove the OnePerRequestModule module:
<system.webServer>
<modules runAllManagedModulesForAllRequests="true">
<add name="OnePerRequestModule" type="Ninject.Web.Common.OnePerRequestHttpModule" />
</modules>
</system.webServer>
This is because this module, is registered dynamically on loadup in the App_Start\Ninject.Web.Common.cs file's Start() method:
public static void Start()
{
DynamicModuleUtility.RegisterModule(typeof(OnePerRequestHttpModule));
DynamicModuleUtility.RegisterModule(typeof(NinjectHttpModule));
bootstrapper.Initialize(CreateKernel);
}
If you don't remove this entry from web.config then you can expect a type exception when launching your application, not least because as part of the version update, the class has moved from the Ninject.Web.Common namespace to Ninject.Web.Common.WebHost.
You can also remove the file App_Start\NinjectWeb.cs for the same reason (registering NinjectHttpModule)
If OnePerRequestHttpModule doesn't resolve in App_Start\Ninject.Web.Common.cs then add the following using statement to the file using Ninject.Web.Common.WebHost; (I think this is a missing reference in v3.3.1 of the package.
Hope this helps others.
I need to update libvncserver and libvncclient libraries to 0.9.11.
I am running CentOS 7.3, currently, the latest libvncserver RPM is 0.9.9
So I took the libvncserver SRPM, modified the spec file, and updated the libvncserver tarball to create a 0.9.11 version of libvncserver and libvncclient RPM's.
I'm having a dependency challenge upon install.
Loaded plugins: fastestmirror
Examining ../RPMS/x86_64/libvncserver-0.9.11-1.el7.centos.1.x86_64.rpm: libvncserver-0.9.11-1.el7.centos.1.x86_64
Marking ../RPMS/x86_64/libvncserver-0.9.11-1.el7.centos.1.x86_64.rpm as an update to libvncserver-0.9.9-9.el7_0.1.x86_64
Examining ../RPMS/x86_64/libvncserver-debuginfo-0.9.11-1.el7.centos.1.x86_64.rpm: libvncserver-debuginfo-0.9.11-1.el7.centos.1.x86_64
Marking ../RPMS/x86_64/libvncserver-debuginfo-0.9.11-1.el7.centos.1.x86_64.rpm to be installed
Examining ../RPMS/x86_64/libvncserver-devel-0.9.11-1.el7.centos.1.x86_64.rpm: libvncserver-devel-0.9.11-1.el7.centos.1.x86_64
Marking ../RPMS/x86_64/libvncserver-devel-0.9.11-1.el7.centos.1.x86_64.rpm to be installed
Resolving Dependencies
--> Running transaction check
---> Package libvncserver.x86_64 0:0.9.9-9.el7_0.1 will be updated
--> Processing Dependency: libvncclient.so.0()(64bit) for package: x11vnc-0.9.13-11.el7.x86_64
Loading mirror speeds from cached hostfile
--> Processing Dependency: libvncserver.so.0()(64bit) for package: x11vnc-0.9.13-11.el7.x86_64
---> Package libvncserver.x86_64 0:0.9.11-1.el7.centos.1 will be an update
---> Package libvncserver-debuginfo.x86_64 0:0.9.11-1.el7.centos.1 will be installed
---> Package libvncserver-devel.x86_64 0:0.9.11-1.el7.centos.1 will be installed
--> Finished Dependency Resolution
Error: Package: x11vnc-0.9.13-11.el7.x86_64 (#epel)
Requires: libvncclient.so.0()(64bit)
Removing: libvncserver-0.9.9-9.el7_0.1.x86_64 (#base)
libvncclient.so.0()(64bit)
Updated By: libvncserver-0.9.11-1.el7.centos.1.x86_64 (/libvncserver-0.9.11-1.el7.centos.1.x86_64)
~libvncclient.so.1()(64bit)
Error: Package: x11vnc-0.9.13-11.el7.x86_64 (#epel)
Requires: libvncserver.so.0()(64bit)
Removing: libvncserver-0.9.9-9.el7_0.1.x86_64 (#base)
libvncserver.so.0()(64bit)
Updated By: libvncserver-0.9.11-1.el7.centos.1.x86_64 (/libvncserver-0.9.11-1.el7.centos.1.x86_64)
~libvncserver.so.1()(64bit)
You could try using --skip-broken to work around the problem
You could try running: rpm -Va --nofiles --nodigest
x11vnc is using libvncserver.so.0 and libvncclient.so.0 from 0.9.9
[localhost SPECS]$ sudo ldd /usr/bin/x11vnc | grep -i vnc
libvncserver.so.0 => /lib64/libvncserver.so.0 (0x00007fee9387d000)
libvncclient.so.0 => /lib64/libvncclient.so.0 (0x00007fee9365f000)
Running the above in verbose, rpm tries to update x11vnc (to there is none)
Potential Provider: libvncserver.x86_64 0:0.9.9-9.el7_0.1
Mode is ud for provider of libvncserver.so.0()(64bit): libvncserver.x86_64 0:0.9.9-9.el7_0.1
Mode for pkg providing libvncserver.so.0()(64bit): ud
Trying to update x11vnc-0.9.13-11.el7.x86_64 to resolve dep
No update paths found for x11vnc-0.9.13-11.el7.x86_64. Failure!
Searching pkgSack for dep: libvncserver.so.0()(64bit)
I could "force-install" but before I do so I'm interested is there a better way to do this? Is it possible to specify dependency checker to not highlight the dependency? Another approach is to create a custom x11vnc RPM, just to update the library path.
The problem is that your package does not provide libvncserver.so.0, but replaces libvncserver, which provides libvncserver.so.0. The easiest solution is to rename your package, so that it can be installed along with the existing libvncserver package.
The -devel subpackage will probably have to conflict with libvncserver-devel because some of the files will overlap, but for the main package, you should be able to enable parallel installation.
You already mentioned the other clean solution: Port all packages from libvncserver.so.0 to libvncserver.so.1. But that could involve quite a bit of unnecessary work and makes your system less similar to others.
(You could also keep the libvncserver package name and create a compat-libvncserver package with the old library, but that's again quite a bit of work for very little benefit.)
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?