python 3.7.6 pip setup.py test with ContextualVersionConflict - setuptools

my setup.py is like below:
from setuptools import find_packages, setup
tests_require = ['pytest-env', 'pytest-mock', 'pytest-cov', 'pytest-xdist', 'pytest', 'mock', 'moto<=1.3.10']
setup(
name='repo_name',
version='0.1.0',
description='repo_name',
keywords=['?'],
packages=find_packages('src', exclude=['tests', 'venv']),
package_dir={'': 'src'},
package_data={'': ['schema/*.yaml']},
install_requires=[
'boto3<=1.10.19',
'requests<=2.22.0',
'jsonschema<=3.0.1',
'objectpath<=0.6.1',
'pyyaml<=5.1.1',
'sqlalchemy<=1.3.5',
'psycopg2-binary<=2.8.3',
'auth-client<=1.0.23', # internal package
'policy_client<=1.0.9', # internal package
'audit-client<=1.1.20', # internal package
'flask<=1.1.1',
'click<=7.0',
'Werkzeug<=0.15.5',
'itsdangerous<=1.1.0',
'Jinja2<=2.10.1',
'MarkupSafe<=1.1.1',
'structlog<=19.2.0',
'python-rapidjson<=0.9.1'
],
setup_requires=['pytest-runner'],
tests_require=tests_require,
extras_require={'test': tests_require},
include_package_data=True,
zip_safe=False
)
When I run python setup.py test, it will always reinstall the most of the packages that I already installed into .eggs folder, which I understand. While it's installing the package with different versions that I provided in the install_requires section, which results in below error:
pkg_resources.ContextualVersionConflict: (urllib3 1.25.10 (/Users/***/Desktop/repo/.eggs/urllib3-1.25.10-py3.7.egg), Requirement.parse('urllib3<1.25,>=1.21.1'), {'requests'})
I have to pin the requests version to 2.22.0 which requires urllib3 version no larger than 1.25, which caused my issue. So, is there anyway I can pin the urllib3 version in somewhere so when it runs, it will only install the provided version? I have tried to add the urllib3 version in install_requires, tests_require and in requirements.txt, but no luck so far.

Probably not what you want to hear but... setup_requires and tests_require are deprecated. Although they (probably) still work (mostly) fine, you might want to look for alternative solutions. As far as I know the most common alternative solutions are to use Tox instead of tests_require and PEP 517 to replace setup_requires.
In your case, it seems that your usage of setup_requires is only a consequence of your usage of tests_require. So by switching to something like Tox you get rid of both tests_require and setup_requires.

I got it resolve to simply replace python setup.py test to be pip instll -e . [test], and then pytest directly.
It will still install all the tests_require packages and then run pytest directly. Instead of going through all the list packages and find the best match versions for all packages.
UPDATES:
The real problem is I did not remove the old .eggs/ and venv/ folder when I made the packages version change. So the solution is updating the requests version to be 2.21.0 in the setup.py file, then remove the .eggs/ and venv/ folder and rerun everything.

Related

Poetry unable to find installation candidates for connectorx

i'm using poetry version 1.2.2 and python 3.11
I want to read the sql query using polars like pl.read_sql()
but it requires the connectorx library.
I am able to install that library using pip install connectorx but poetry add connectorx is giving this error:
RuntimeError
Unable to find installation candidates for connectorx (0.3.1)
at ~\AppData\Local\Programs\Python\Python311\Lib\site-packages\poetry\installation\chooser.py:103 in choose_for
99│
100│ links.append(link)
101│
102│ if not links:
→ 103│ raise RuntimeError(f"Unable to find installation candidates for {package}")
104│
105│ # Get the best link
106│ chosen = max(links, key=lambda link: self._sort_key(package, link))
107│
Tried clearing the cache of poetry
Tried adding into pyproject.toml
connectorx neither provide a wheel file for python 3.11 nor a source distribution from which a wheel could be build. See https://pypi.org/project/connectorx/#files
So there is no way to install it on python 3.11

How to check compatibility of packages in setup.py wihout installation?

I use a setup.py to declare the python libraries to include in the package of my solution.
Is there a way to check the libraries compatibility using setup.py without installing the package? Because for now I can detect the conflicts only when I try to install my package.
Thank you
I think if I were you I would try with dephell. I don't think it will be able to give you a clear answer without tweaking, but it might help you get a bit closer to the info you are looking for. For example you could try these commands:
dephell deps check --from setuppy
-- https://dephell.readthedocs.io/cmd-deps-check.html
or
dephell deps tree --from setuppy
-- https://dephell.readthedocs.io/cmd-deps-tree.html

ModuleNotFoundError: No module named 'cartopy' when import SkewT from metpy.plots under Python3

When trying to import SkewT into my python3 code on a Mac (Mojave 10.14.6):
from metpy.plots import SkewT
I get the error:
ModuleNotFoundError: No module named 'cartopy'
pip3 install cartopy gives the output
Collecting cartopy
Downloading https://files.pythonhosted.org/packages/e5/92/fe8838fa8158931906dfc4f16c5c1436b3dd2daf83592645b179581403ad/Cartopy-0.17.0.tar.gz (8.9MB)
|████████████████████████████████| 8.9MB 616kB/s
Installing build dependencies ... done
Getting requirements to build wheel ... error
ERROR: Complete output from command /usr/local/opt/python/bin/python3.7 /usr/local/lib/python3.7/site-packages/pip/_vendor/pep517/_in_process.py get_requires_for_build_wheel /tmp/tmpj50b1vfe:
ERROR: setup.py:171: UserWarning: Unable to determine GEOS version. Ensure you have 3.3.3 or later installed, or installation may fail.
'.'.join(str(v) for v in GEOS_MIN_VERSION), ))
Proj 4.9.0 must be installed.
----------------------------------------
ERROR: Command "/usr/local/opt/python/bin/python3.7 /usr/local/lib/python3.7/site-packages/pip/_vendor/pep517/_in_process.py get_requires_for_build_wheel /tmp/tmpj50b1vfe" failed with error code 1 in /private/tmp/pip-install-b5cu8485/cartopy
To start, I tried to install Proj and geos, but pip3 only lists version 0.1.0 for proj and 0.2.2 for geos. Before I get too far down this rabbit hole, I thought I'd see if anyone else has encountered this problem. Thanks!
So it looks like MetPy 0.10 accidentally picked up a hard dependency on CartoPy, which we did not really plan. You can track our resolution of that here.
CartoPy depends on a lot of compiled libraries that are not pip-installable unfortunately. Your best bet is to look at CartoPy's install instructions. If you're using Anaconda or Canopy, those distributions have pre-built CartoPy packages available.
One option to work around this is to install MetPy 0.9:
pip install metpy==0.9
Do you use Conda? The easiest way to remedy this problem is to install CartoPy (or MetPy for that manner) via conda, so that all of the right dependencies are also downloaded: conda install -c conda-forge cartopy or conda install -c conda-forge metpy. Pip doesn't bring all of them together, so that leads to this problem being raised.
Thanks. Without conda, I was also able to complete this (more painful) installation:
- brew install geos
- brew install proj
- pip3 install cython
- pip3 install git+https://github.com/SciTools/cartopy.git#master 
(see http://louistiao.me/posts/installing-cartopy-on-mac-osx-1011/)

Specify RPM build order in mock

TLDR: Ensure to keep system OS up-to-date to help ensure consistency with current spec files.
Symptom
When rebuilding PostgreSQL 11.1 SRPM using mock, the build fails with:
BUILDSTDERR: /builddir/build/BUILD/postgresql-11.1/src/bin/psql/command.c:1814 undefined reference to `PQencryptPasswordConn`
NB: PQencryptPasswordConn is a libpq.so function (provided by postgresql-devel-10.3-5.fc27.x86_64 on my system...outside the mock chroot environment). Unless I'm mistaken, the Postgresql SRPM builds the postgresql-devel RPM along with others.
Steps to reproduce
I ran the following to rebuild the SRPM before attempting to apply any patches not already present in the SRPM:
# Obtain SRPM source
git clone https://src.fedoraproject.org/rpms/postgresql.git
cd postgresql
# Download local copies of SRPM sources
wget $(spectool -S *.spec | awk '/^Source.*:\/\//{IFS=" "; print $2}')
# ...check SHAs of downloaded sources...
# Run SRPM-specific prep scripts
./generate-pdf.sh
./generate-sources.sh
# Generate the SRPM
mock --root=fedora-27-x86_64 --resultdir="./SRPMS" --buildsrpm --spec postgresql.spec --sources .
# >>> Everything seems to work fine up to this point <<<
# Build the RPM inside mock chroot
mock --root=fedora-27-x86_64 --rebuild ./SRPMS/postgresql-11.1-4.fc27.src.rpm
# !!! Fail here (with symptom above) !!!
The Problem
I have so far been unable to have mock load the appropriate libpq library headers into the chroot environment to make sure rpmbuild builds against the libpq that contains the PQencryptPasswordConn header (which appears to exist on my system outside the build environment):
grep -lr "PQencryptPasswordConn" /usr/include
# /usr/include/libpq-fe.h
grep -lr "PQencryptPasswordConn" /var/lib/mock/fedora-27-x86_64/root/usr/include
# (Nothing returned)
When reviewing mock's installed_pkgs.log, the following were installed (the latter of which I expect would provide a version of libpq headers):
postgresql-libs-9.6.10-3.fc27.x86_64
postgresql-devel-9.6.10-3.fc27.x86_64
However, I cannot find a way to install the postgresql-* packages into the chroot environment that contain the updated library headers.
The Ask
Since postgresql SRPM is supposed to build postgresql-devel RPM, I think that mock will need to build and install the postgresql-devel RPM in the chroot before rpmbuild attempts to compile psql/command.c so that the latter compilation finds the appropriate library headers (unless the build process is intelligent enough to identify new libraries currently under build).
How can I best accomplish this (would prefer to avoid multiple mock calls for each RPM package built from the SRPM unless that's the only way to go)?
Please note that the build process on my system spawns multiple processes to parallel compilations.
I have also tried to use mockchain —recurse without success.
System Info
Linux 4.16.6-202.fc27.x86_64
First hint, you use the latest postgresql.spec version, but you try to build it against rather old (in fact unsupported nowadays) version 27 of Fedora distribution. I'd encourage you to migrate to a newer version of Fedora, or at least checkout the branch f27 in the same RPM git repository.
Second hint, we changed the layout of PostgreSQL packaging in Fedora 30+. We've cut out the library (libpq.so) into separate package, per announcement.
How to continue; always checkout appropriate branch based on what Fedora you build against, and adjust the spec file appropriately (checkout f27 and update to PostgreSQL 11.1 in this case).
JFTR (might help), there already is a testing modular build of PostgreSQL 11 against Fedora 28+, and the build scripts are maintained in separate branch stream-postgresql-11. With a bit of luck, you would be able to build that branch against old Fedora 27, too. Note that this version of postgresql.spec file is a little bit complicated (it needs to be because we build it against different versions of Fedora).

Error running purescript example

I'm trying to learn purescript starting with the simple "Hello World" from "Purescript by Example".
Issuing a "pulp run" throws this error:
* Building project in /home/peter/devel/purescript/my-project
Error found:
at bower_components/purescript-psci-support/src/PSCI/Support.purs line 21, column 1 - line 21, column 1
Unable to parse module:
unexpected "else"
expecting declaration or end of input
purs is of version 0.11.7, Pulp is version 12.2.0.
What am I doing wrong?
Thanks for your help.
The recent release of PureScript 0.12 has introduced breaking changes. Several new package versions will not work on older compilers. If you want to stay pre-0.12, and you are using bower, then do this to your project:
Delete all contents in the bower_components directory.
Downgrade all package versions in bower.json to pre-0.12 versions, such as prelude 3.2.0, console 3.0.0, and psci-support 3.0.0. You can use Pursuit and look at older bower.json files on GitHub to figure out these versions.
Run bower install.
Run pulp build.
Alternatively, you can upgrade to 0.12 with PureScript Version Manager. At this time 0.12 is not available on npm. To do this you can follow these installation instructions but in short is:
Uninstall the old compiler: npm uninstall -g purescript.
Install PSVM: npm install -g psvm.
Download 0.12: psvm install-latest.
Install 0.12: psvm use v0.12.0
Add PSVM's bin directory to your PATH which is C:\Users\<username>\.psvm\current\bin on Windows. Make sure your current session is updated with this new PATH variable.
Test out the new compiler: purs --version.
I'm working through PureScript by Example and ran into the same issue today. I stumbled across issue 3367, where gabejohnson directs us to the blog post, Working with 0.11.7 in a 0.12 world.
Long story short, it seems like PureScript 0.12 has introduced breaking changes, just like erisco said, and we should use psc-package instead of bower if we want to stay on 0.11.7 (because pulp doesn't work with PureScript 0.12 at the moment and bower is giving the team issues with dependency management).
You can install psc-package either with the binary or using npm install -g psc-package.
After that, you will need to tell pulp to use psc-package when you init a new project using pulp --psc-package init. Finally, install the lists package with psc-package install lists.
Keep in mind that packages do not have the purescript- prefix when using psc-package, so you just pass in the package name.
This is what got me back on track and I hope this helps you too.