Pyomo Util Module Not Found - pyomo

So I asked a question a month ago. I had a really nice answer to that question. I wanted to test if the answer works right now. But I am getting ModuleNotFoundError.
I did following before testing:
conda install -c conda-forge pyomo
conda install -c conda-forge pyomo.extras
I want to run this script in my code (copy/pasted from the other question):
from pyomo.util.infeasible import log_infeasible_constraints
...
SolverFactory('your_solver').solve(model)
...
log_infeasible_constraints(model)
Error I encounter:
N:\urbs>python runme.py
Traceback (most recent call last):
File "runme.py", line 9, in <module>
from pyomo.util.infeasible import log_infeasible_constraints
ModuleNotFoundError: No module named 'pyomo.util.infeasible'
How to install it then? I checked doc etc..., could not find a way.

Pyomo 5.5 (the latest released version as of 23 August 2018) does not yet have that feature. I had mistakenly assumed that it was included. You can either change your version of pyomo to track master, or more easily, you can simply take the function at https://github.com/Pyomo/pyomo/blob/master/pyomo/util/infeasible.py and place it in your own code (along with the associated required imports).

Related

pip installer seems not to write in the PATH in a Python server

I tried to download Graphlab from Turi wit the following tutorial. I coded with their tools and tried to compute a Python script but it answered me an ImportError.
(gl-env)ubuntu#ip-172-hey-hey-hey:~/Eclipse-Stats$ source deactivate
discarding /home/ubuntu/anaconda2/envs/gl-env/bin from PATH
ubuntu#ip-172-hey-hey-hey:~/Eclipse-Stats$ unset PYTHONPATH
ubuntu#ip-172-hey-hey-hey:~/Eclipse-Stats$ python Main.py
2017-07-27 14:56:00.520425
/home/ubuntu/.local/lib/python2.7/site-packages/sklearn/cross_validation.py:44: DeprecationWarning: This module was deprecated in version 0.18 in favor of the model_selection module into which all the refactored classes and functions are moved. Also note that the interface of the new CV iterators are different from that of this module. This module will be removed in 0.20.
"This module will be removed in 0.20.", DeprecationWarning)
Traceback (most recent call last):
File "Main.py", line 3, in <module>
import prediction
File "/home/ubuntu/Eclipse-Stats/prediction.py", line 1, in <module>
from graphlab.toolkits.recommender import ranking_factorization_recommender
ImportError: No module named graphlab.toolkits.recommender
Actually it cames often on the server when I tried to download with pip numpy, scipy, sklearn... Like we can see in the following conversation (in Spanish) between FJSevilla and the man of my team I'm working with.
Two things: (1) check the version of your Python console and see if it matches or is higher than the compatibility with the packages. If you look at the depreciation message and read it through, you would understand what is going on a little more. (2) be careful of what you are importing and how you import them because your formatting might also be a syntactic all error. One thing you could do is find the package, manually download, unzip, then run the setup.py.

OpenCV 3.2.0-dev - 3.2.0 version missing RTrees, unable to find dev version

OpenCV 3.2.0 seems does not have RTrees library.
But internet is full of examples of cv2.RTrees. I thought maybe be the issue of versions mismatching - maybe version is wrong ? Should it be 3.2.0-dev ?
But on Fedora 24 i cant seem to find this package nor on the internet. All i see that only ubuntu users can install 3.2.0-dev. Am i missing something ?
>>> import cv2
>>> cv2.__version__
'3.2.0'
>>> cv2.RTrees
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
AttributeError: 'module' object has no attribute 'RTrees'
>>> cv2.ml.RTrees
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
AttributeError: 'module' object has no attribute 'RTrees'
Most examples of RTrees you could find before this date on the internet are from versions 2.4.x. This is because as of mid January there was still no wrapper for Python of the RTrees model of OpenCV, as we can see in this question on the OpenCV answers page. Quoting from it (user berak on Jan 12 '17:
unfortunately, this is not possible atm., as of opencv3.2, only SVM and ANN_MLP have correctly wrapped load methods.
(yes, it's a bug)
Searching a bit more it was found that this issue was fixed recently (as pointed out in this question); you can see this functionality was added in this pull request on the OpenCV git.
Therefore, updating to the latest master branch and rebuilding should fix the problem.
Note: Remember to clone the main repository (opencv), which is the one who actually contains the RTrees model, and if you are using it also clone the contrib repository (opencv_contrib). Do checkout the same version on each to avoid compatibility issues.
Bonus: Check this great installation guide for OpenCV, which also provides some additional recommendations like using venv for the installation (it also has guides for other OS).

fixing matplotlib/numpy dependency hell in Anaconda

I'm running Python 2.7.11 under Anaconda 2.0.0 (x86_64) on a MacBook.
Some weeks ago, as part of a process of getting OpenCV working, I downgraded numpy from wherever it was (unfortunately/stupidly I have no record) to 1.7.1. I seem to remember this was necessary, and I do not want OpenCV to stop working, so I'm pretty sure I should now leave numpy where it is.
However, today I discovered that this has broken my matplotlib/pylab. When I do import pylab I get the following:
---------------------------------------------------------------------------
RuntimeError Traceback (most recent call last)
RuntimeError: module compiled against API version 9 but this version of numpy is 7
---------------------------------------------------------------------------
ImportError Traceback (most recent call last)
...
...
ImportError: numpy.core.multiarray failed to import
My question, therefore, is: how do I install (or roll back to) a version of matplotlib that's compatible with my existing numpy, without disturbing my existing numpy?
Here's where I've got so far: based on related conda questions on SO, I looked at the output of conda list --revisions matplotlib which includes:
...
2016-03-28 17:16:36 (rev 6)
conda {3.8.3 -> 4.0.5}
conda-env {2.0.1 -> 2.4.5}
numpy {1.8.1 -> 1.7.1}
...
Now I'm not sure how to interpret this but given the numpy version number looks like it's actually falling in contrast to all the other entries here, this sounds to me like a promising, "in March 2016 matplotlib realized it could fall back to an earlier version of its numpy dependency". However, when I ask for this revision:
conda install --revision=6 matplotlib
I'm told I already have it, and that its dependency is numpy 1.8:
Fetching package metadata: ....
# All requested packages already installed.
# packages in environment at /Users/jez/anaconda:
#
matplotlib 1.3.1 np18py27_1 <unknown>
So from here I'm not sure how to proceed. I've tentatively played with some variations on conda install matplotlib, but it clearly wants to mess with my numpy at the same time, so I have never pressed y. Equally clearly, I'm out of my depth in conda, so would really appreciate your help.
You can specify the exact versions of any libraries you want in the conda install command. For example:
$ conda install numpy=1.7.1 matplotlib=1.3
If the versions are incompatible, the command will give you an error specifying exactly what the incompatibility is.

Problems Running django-autocomplete-light test_application

So I have a virtualenv with the following installed modules:
Django (1.7.7)
django-autocomplete-light (2.1.0rc3, /Users/username/.virtualenvs/testaclite/src/autocomplete-light)
django-autoslug (1.7.2)
django-cities-light (3.1.2)
pip (6.0.8)
setuptools (12.0.5)
six (1.9.0)
South (1.0.2)
Unidecode (0.4.17)
Using the following instructions from the README.rst file that comes with the test project for django-autocomplete-light, I then go to the folder /Users/username/.virtualenvs/testaclite/src/autocomplete-light/test_project
I then execute ./manage.py runserver and get the following result:
Traceback (most recent call last):
File "./manage.py", line 8, in <module>
from django.core.management import execute_from_command_line
ImportError: No module named django.core.management
What's going on here? How can I debug this and move forward?
This specific problem was due to an oversight on my part. I did not have my python virtual environment activated. Therefore, python was not being loaded at that moment.
Hopefully, others will benefit from this and not make the same mistake I did.
That being said, the test_project still doesn't fully work. It is full of page not found errors. Maybe it will be repaired / updated soon.
The README has just been fixed, sorry about that.
There was two mistakes in the README:
https://github.com/yourlabs/django-autocomplete-light/commit/d23d2ce0aaf1b657e95486e47a2fe1b10242e257
https://github.com/yourlabs/django-autocomplete-light/commit/5d36be09f0fa3055fc785f2c4d048f927eb57792
I hope everything is working now, feel free to ping us with your question URL on #yourlabs on IRC or on the mailing list.

Python version, "2.7.2+", what does the plus mean?

I have a virtual environment that I installed some time ago. When I activate it and run python I'm told that the version number is
Python 2.7.2+ (default, Oct 4 2011, 20:03:08)
What does the plus after the version number mean?
And could that somehow explain why the function os.urandom is not defined, even when (according to the documentation) it has been there since version 2.4.
>>> from os import urandom
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ImportError: cannot import name urandom
From the Python FAQ:
You may also find version numbers with a “+” suffix, e.g. “2.2+”.
These are unreleased versions, built directly from the CPython
development repository. In practice, after a final minor release is
made, the version is incremented to the next minor version, which
becomes the “a0” version, e.g. “2.4a0”.
And for your second question, the inability to import urandom in a virtualenv is a known problem.
This answer to a similar question should be helpful.