arcgis-python-api
arcgis-python-api copied to clipboard
pip install arcgis==2.0.1 fails on MacOS
Describe the bug
Cannot install arcgis Python SDK v2.0.1 on MacOS using pip install .. which makes server installs using requirements.txt difficult (arcgis Python SDK v2.0.0 installs just fine).
To Reproduce
Steps:
pip install arcgis==2.0.1
Error:
pip install arcgis==2.0.1
ERROR: Ignored the following versions that require a different python version: 2.0.1 Requires-Python >=3.7, <3.10
ERROR: Could not find a version that satisfies the requirement arcgis==2.0.1 (from versions: 1.3.0, 1.3.0.post1, 1.3.0.post2, 1.4.0, 1.4.1, 1.4.2, 1.5.0, 1.5.1, 1.5.2, 1.5.2.post1, 1.5.3, 1.6.0, 1.6.1, 1.6.1.post1, 1.6.2, 1.6.2.post1, 1.7.0, 1.7.1, 1.8.0, 1.8.0.post1, 1.8.1, 1.8.2, 1.8.3, 1.8.3.post1, 1.8.3.post2, 1.8.4, 1.8.5.post1, 1.8.5.post2, 1.8.5.post3, 1.9.0, 1.9.1, 2.0.0)
ERROR: No matching distribution found for arcgis==2.0.1
Expected behavior A clear and concise description of what you expected to happen.
Platform (please complete the following information):
- OS: MacOS
- Python API Version [e.g.
2.0.1]
Additional context
pip install arcgis=2.0.0 works just fine.
Related:
- https://github.com/Esri/arcgis-python-api/issues/1299
pip install arcgis==2.0.1 installs successfully for Python 3.9 but is not marked as available for Python 3.10 on pypi:
Requires: Python >=3.7, <3.10
2.0.1 is available for Python 3.9:
python --version
Python 3.9.12
pip index versions arcgis
arcgis (2.0.1)
Available versions: 2.0.1, 2.0.0, 1.9.1, 1.9.0, 1.8.5.post3, 1.8.4, 1.8.3.post2, 1.8.3.post1, 1.8.3, 1.8.2, 1.8.1, 1.8.0.post1, 1.8.0, 1.7.1, 1.7.0, 1.6.2.post1, 1.6.2, 1.6.1.post1, 1.6.1, 1.6.0, 1.5.3, 1.5.2.post1, 1.5.2, 1.5.1, 1.5.0, 1.4.2, 1.4.1, 1.4.0, 1.3.0.post2, 1.3.0.post1, 1.3.0
2.0.0 is the latest available for Python 3.10:
python --version
Python 3.10.4
pip index versions arcgis
arcgis (2.0.0)
Available versions: 2.0.0, 1.9.1, 1.9.0, 1.8.5.post3, 1.8.4, 1.8.3.post2, 1.8.3.post1, 1.8.3, 1.8.2, 1.8.1, 1.8.0.post1, 1.8.0, 1.7.1, 1.7.0, 1.6.2.post1, 1.6.2, 1.6.1.post1, 1.6.1, 1.6.0, 1.5.3, 1.5.2.post1, 1.5.2, 1.5.1, 1.5.0, 1.4.2, 1.4.1, 1.4.0, 1.3.0.post2, 1.3.0.post1, 1.3.0
Hello,
We do not support past Python 3.9, we are looking at viability with 3.10 and 3.11 for upcoming releases but can only ensure it'll work with up to 3.9 for now. Hope that helps!
Thanks for the info - I'll downgrade my Python to 3.9
when do you plan to add support python 3.10 or higher?
next release we are targeting: Python 3.9, 3.10, and 3.11 and dropping support for Python 3.7 and 3.8
Any update on when this release is going to come out?
@davidemerritt The beta version of 2.2.0 is available for install but the official release will be in September
Thank you @nanaeaubry - what is the preferred method of installation for the beta version? Can it be specified with pip, or does it have to be manually installed?
@davidemerritt For conda: conda install -c "esri/label/prerelease" arcgis
There isn't pip for pre-release
Thanks - I'll check it out.
What type of chipset do you have for your Mac?
This will be running on dockerized ubuntu.
On Thu, Jul 20, 2023 at 12:19 PM Andrew @.***> wrote:
What type of chipset do you have for your Mac?
— Reply to this email directly, view it on GitHub https://github.com/Esri/arcgis-python-api/issues/1323#issuecomment-1644218380, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA5EVAM664IUCQQU4NEY4IDXRFLB7ANCNFSM556YQYDA . You are receiving this because you were mentioned.Message ID: @.***>
I actually can't use anaconda with the existing pip environment for production. Is there any public facing repo that I can fork and update the python_dependencies to allow this until the new release version comes out in september?
@davidemerritt Unfortunately there is no public facing repo to fork from
Got it - perhaps I should make a new issue to ask this, and if it makes sense I will, but has the organization considered making a lightweight client for the arcGIS interaction functionality? Currently including numpy, jupyter, pandas, matplotlib, pillow etc as dependencies makes this library unrealistic to use in a production environment. I imagine that a lot of that is optional functionality, and could be included optionally if split up into arcgis[reporting] etc like other libraries do.
Our use case is sending api requests to arcgis modifying a feature set with some light featureset manipulation.
@davidemerritt This is definitely in the plans, thanks for adding that opinion as it will help us push forward on it. We don't have a timeline as of now but we do have it on our radar.