GeospatialPython/pyshp

Release as Python 3 source wheel on PyPI?

deeplook opened this issue · 7 comments

deeplook commented

It seems one could install pyshp on Pyodide and hence JupyterLite using micropip if it would have a source wheel package on PyPI. Maybe worth a thought?

alexandreCameron commented

The following comment is related to the title of this issue, but it is not related to the last two posts.

Thank

I'd like to thank all the contributors of the projects for providing an working open source solution that work reliably.

OpenQuake

This package is currently used by the OpenQuake Engine https://github.com/gem/oq-engine .

The OpenQuake project is used to analyze earthquakes around the world for scientific purposes.

Recently, the project updated all of it's dependency except pyshp gem/oq-engine#7322

The pyshp requirement is still locked on version 1.2.3 because of incompatibilities with python 3.

As a reminder, numpy dropped support for python 2.7 in 2020 https://numpy.org/doc/1.14/neps/dropping-python2.7-proposal.html

Python 3

pyshp==1.2.3 (22nd June 2015)

pyshp used to have a support for python3

pyshp==1.2.3 (22nd June 2015) shapefile.py:

PYTHON3 = sys.version_info[0] == 3

[...]

def is_string(v):
    if PYTHON3:
        return isinstance(v, str)
    else:
        return isinstance(v, basestring)

pyshp== 2.1.3 (14th Jan 2021) latest release

The latest version of the package does not seem to support python3 conventions

pyshp==2.1.3 (14th Jan 2021) shapefile.py:

    def is_string(v):
        return isinstance(v, basestring)

Python does not support basestring anymore

The built-in basestring abstract type was removed. Use str instead. The str and bytes types don’t have functionality enough in common to warrant a shared base class. The 2to3 tool (see below) replaces every occurrence of basestring with str.

https://docs.python.org/3/whatsnew/3.0.html

Note that other keywords are not valid any more in python3 such as unicode

As a consequence of this change in philosophy, pretty much all code that uses Unicode, encodings or binary data most likely has to change. The change is for the better, as in the 2.x world there were numerous bugs having to do with mixing encoded and unencoded text. To be prepared in Python 2.x, start using unicode for all unencoded text, and str for binary or encoded data only. Then the 2to3 tool will do most of the work for you.

Help

Would it be possible to release a version of this pyshp compatible with python3 ?

@GeospatialPython @karimbahgat , you are the two main contributors on the project, would you be able to give some insight ?

karimbahgat commented

@deeplook or @micahcochran i'm in the process of releasing a new version, which i'll be doing for the first time using github actions. There i added i made the build command "python -m build --sdist --wheel --outdir dist/" in an ubuntu python3 environment (https://github.com/GeospatialPython/pyshp/blob/master/.github/workflows/deploy.yml). I'm not sure if this is sufficient to build and upload a wheel to pypi, but if you want micropip support in the next version i'll gladly take any suggestions or PRs.

karimbahgat commented

@alexandreCameron i would definitely suggest an upgrade from v1.2.3 to 2.1.3, as there have been plenty of bug fixes, performance improvements, and new features. However, the python 2 artifacts you are referring to (unicode, basestring, etc) are inside an if-clause that only gets triggered if the version is python 2. As indicated in the project readme, pyshp continues to support and run smoothly for both python 2.7 and 3+, backed up by doctests and unittest. So if you're having problems when upgrading to a later version, i suspect the errors are rather due to backwards incompatible changes after the major version bump to v2. I'm adding more details in the openquake issue thread you referenced.

  • 👍1
micahcochran commented

@deeplook or @micahcochran i'm in the process of releasing a new version, which i'll be doing for the first time using github actions. There i added i made the build command "python -m build --sdist --wheel --outdir dist/" in an ubuntu python3 environment (https://github.com/GeospatialPython/pyshp/blob/master/.github/workflows/deploy.yml). I'm not sure if this is sufficient to build and upload a wheel to pypi, but if you want micropip support in the next version i'll gladly take any suggestions or PRs.

I haven't make GitHub workflows do deployment. Over the past few years PyPA have been changing the way to build and upload projects, to "pip". Twine is pretty easy to use.

If you are still trying to support Python 2.7 with wheels, you may have to use an older syntax. (Once, I had to look up the older syntax for PyPA's documentation to support Python 3.5/3.6. I used an archive.org version of the website to see what the manual's instructions said a couple years ago.)

karimbahgat commented

@micahcochran I think the Github workflow I've setup already uses twine in the background, and I believe it should produce a wheel and upload it, but just wanted to see if any of you had any more direct experience with it. For the purpose of the wheels, which would only be relevant for the purpose of pyodide/micropip as described by the OP, I think avoiding the complexity and only supporting Python 3 wheels would be sufficient.

karimbahgat commented

@deeplook v2.2.0 is now out on pypi with a source wheel ('pyshp-2.2.0-py3-none-any.whl'). Does this fix the issue for pyodide/jupyterlite/micropip?