Im relatively new to python world.
Im trying to install wxpython on several computers and it keeps failing.
I use anaconda version 4.9.2 and use the prompt command:
conda install -c anaconda wxpython
I get the following error message:
Collecting package metadata (current_repodata.json): done
Solving environment: failed with initial frozen solve. Retrying with flexible solve.
Solving environment: failed with repodata from current_repodata.json, will retry with next repodata source.
I try updating python to latest version. I try a number of things. and still I get this pesky problem. What am I doing wrong?
Thanks!
Nothing wrong per se. Those messages are indicating that Conda can't install that package without changing the currently installed packages. Because the Anaconda distribution (!= Conda) has lots of packages this happens very frequently. Also, this particular package is not updated frequently and the anaconda channel doesn't even seem to keep pace with that.
In general, it is better practice is to create new environments for each project/task you have to work on, and only install the packages you require. Also, the conda-forge channel tends to be a more consistent provider for packages, but undergoes less interoperability testing and tuning than the Anaconda channel packages. That is, consider trying something like
conda create -n myenv -c conda-forge python=3.9 wxpython ...
where myenv is whatever you would like to refer to the environment as, and ... should be whatever other packages you know you would like to use.
Related
I tried installing orthofinder like this:
conda install -c bioconda orthofinder
But it returns the following:
Collecting package metadata (current_repodata.json): done
Solving environment: failed with initial frozen solve. Retrying with flexible solve.
Solving environment: failed with repodata from current_repodata.json, will retry with next repodata source.
Collecting package metadata (repodata.json): done
Solving environment: failed with initial frozen solve. Retrying with flexible solve.
Solving environment: /
Found conflicts! Looking for incompatible packages.
This can take several minutes. Press CTRL-C to abort.
failed
UnsatisfiableError: The following specifications were found to be incompatible with each other:
Output in format: Requested package -> Available versions
What is going on?
I am using conda 4.9.2 installed using Homebrew.
I also tried with a newer version of conda and it gives the same error.
Got solved using the zsh shell. I have no idea why but it worked. If someone knows please let me know.
I attempted to upgrade my tcms-api library from 5.0 to 5.3 using:
pip install tcms-api --upgrade
on a Windows 10 machine, I saw a lot of errors when trying to install the dependent package of kerberos. Even though this is old, I saw a similar set of errors. The package installation failed since the kerberos package isn't supported on Windows and I was left at tcms-api 5.0.
Please file a bug against https://github.com/kiwitcms/tcms-api.
We can do a quick fix by providing 2 package names:
tcms-api and tcms-api[kerberos]
The first one will not install the kerberos package.
The proposed workaround makes sense but changing the underlying kerberos implementation needs careful testing which isn't a quick job.
OTOH https://github.com/kiwitcms/python-social-auth-kerberos uses gssapi which seems to be the latest and most actively maintained implementation of Kerberos for Python. There is an open issue to migrate to that in tcms-api so you can contribute if you want.
As a workaround, I was able to do the following (caveat: I haven't extensively tested my installation yet):
Clone the tcms-api repo from GitHub
Edit setup.py to change the install_requires line to use 'kerberos-sspi' rather than 'kerberos'
Install the following pip packages: Setuptools, Wheel, Twine
CD to repo folder and run: python setup.py bdist_wheel
That creates a package under the dist folder
Run pip install dist\tcms_api-5.3-py3-none-any.whl
Celebrate successful package install
The steps were modified from this page.
Update:
I confirmed the things I need the API to do work with my custom package (create and update test runs). However, I'm in a situation where I don't need to specifically harden my Kiwi instance using kerberos authentication.
Hello guys. Can someone help me about this one? I cant install mongodb because of dependency problem. I already tried updating my linux mint terminal.
dpkg: dependency problems prevent configuration of mongodb-enterprise-server:
mongodb-enterprise-server depends on libcurl3 (>= 7.16.2); however:
Package libcurl3 is not installed.
mongodb-enterprise-server depends on snmp; however:
Package snmp is not installed.
Installing via dpkg -i mongodb.deb will not include additional package dependencies. You should be able to fix your installation by following up with sudo apt --fix-broken install.
Unless you have strong reasons to avoid the standard process I would recommend following the tutorial to Install MongoDB Enterprise by adding the appropriate repo definitions. Adding the normal package repo will also make it easier for you to update to newer minor releases of MongoDB 4.0.x.
I've been trying to install MacPorts on a new Mac Pro with a fresh, fully updated Yosemite OS. The installer hangs on 'Running package scripts'. So I tried to build it from source. That works, with the installer stating:
Congratulations, you have successfully installed the MacPorts system.
However, it seems unusable. When I do sudo port install apache2 I get the message:
Error: Port apache2 not found
Simply trying to do a 'self update' (as root):
sh-3.2# port -d selfupdate
DEBUG: MacPorts sources location: /opt/local/var/macports/sources/rsync.macports.org/release/tarballs
---> Updating MacPorts base sources using rsync
receiving file list ... done
base.tar
...and then nothing... I've waited for half an hour, but it won't go any further. I can't find any logs either.
Again: there's nothing special about my setup, it's out-of-the-box Yosemite, only updated through the App store and, of course, I've installed Xcode with command line utilities and formally accepted the license, as is required according to the MacPorts site.
I've also tried uninstalling it, using the instructions from the MacPorts site, and reinstalling. But it does not make a difference.
I've read quite a few forum posts, but I can't find any post relating a problem like this. I hope someone can shed some light on this.
The installer hangs running package scripts because the last statement in these package scripts is exactly this "sudo port selfupdate" that you've been running manually afterwards.
Because this step did never run, your MacPorts installation lacks knowledge about the apache2 port (which is exactly why the installer runs selfupdate to give you a full-featured installation).
Unfortunately Apple's infrastructure (rsync.macports.org) seems to have connectivity problems at the moment, which is causing problems for quite a few people. You can try using one of the mirrors as outlined at https://trac.macports.org/wiki/Mirrors.
I would like to create an RPM package that applies a Puppet manifest on a server which does not contain Puppet, Facter and Hiera.
Also, and more importantly, I should be able to apply it WITHOUT being obliged to install neither of these tools (Puppet, Facter, Hiera) on the production server.
So basically, the package should run the following command without installing any of the required packages:
puppet apply install.pp --modulepath=./modules --hiera_config=./conf/hiera.yaml
How can I proceed to make such a package ? Is it a good idea to extract the 'binary' files the Puppet/Hiera/Facter RPMs to include them in another one ?
Thanks!
Installing the relevant packages and then removing them would be by far the fastest and safest way to do what you wish. Maybe you can convince your customer that the cost in time for any other solution is not worth the money.
Anyway, if packages are not an option, let's be innovative:
You do not have to install from packages, you can install puppet via ruby gems
In the same way, you can use source tarballs
Those two options might work, but are not innovative enough.
What about installing puppet 'locally' on a disk via the gems or the tarballs, and then mounting this disk via nfs?
While we are here, why not do the same but then mount using sshfs?
still with the idea of a having first a remote install, you could indeed repackage it via fpm (amazing tool, very strongly recommended). You still end up with a package, but a local one which will not require adding a repository, this might alleviate some of your client concerns.
building on this, if the issue is with repositories, not packages, you could download all required packages and install them manually
I guess that the summary of this answer is that the value of doing so is negative compared to using what you distribution provides.