Invalid literal installing ics

Installs fine on other platforms. Any workarounds?

[~/Documents]$ pip install ics
Querying PyPI ... 
stash: <class 'ValueError'>: invalid literal for int() with base 10: ''
Traceback (most recent call last):
  File "/private/var/mobile/Containers/Shared/AppGroup/E94427DA-467A-4A3E-8A3C-59C6EE530946/Pythonista3/Documents/site-packages/stash/system/shruntime.py", line 546, in exec_py_file
    exec (code, namespace, namespace)
  File "site-packages/stash/bin/pip.py", line 1572, in <module>
    repository.install(pkg_name, ver_spec, flags=flags, extras=extras)
  File "site-packages/stash/bin/pip.py", line 1168, in install
    archive_filename, pkg_info = self.download(pkg_name, ver_spec, flags=flags)
  File "site-packages/stash/bin/pip.py", line 1056, in download
    hit = self._determin_hit(pkg_data, ver_spec, flags=flags)
  File "site-packages/stash/bin/pip.py", line 1206, in _determin_hit
    versions = [latest] + _stash.libversion.sort_versions(self._package_releases(pkg_data))
  File "/private/var/mobile/Containers/Shared/AppGroup/E94427DA-467A-4A3E-8A3C-59C6EE530946/Pythonista3/Documents/site-packages/stash/lib/libversion.py", line 120, in sort_versions
    return sorted(versionlist, key=lambda s: Version.parse(s) if isinstance(s, str) else s, reverse=True)
  File "/private/var/mobile/Containers/Shared/AppGroup/E94427DA-467A-4A3E-8A3C-59C6EE530946/Pythonista3/Documents/site-packages/stash/lib/libversion.py", line 120, in <lambda>
    return sorted(versionlist, key=lambda s: Version.parse(s) if isinstance(s, str) else s, reverse=True)
  File "/private/var/mobile/Containers/Shared/AppGroup/E94427DA-467A-4A3E-8A3C-59C6EE530946/Pythonista3/Documents/site-packages/stash/lib/libversion.py", line 166, in parse
    parsed = _parse_version(s)
  File "/private/var/mobile/Containers/Shared/AppGroup/E94427DA-467A-4A3E-8A3C-59C6EE530946/Pythonista3/Documents/site-packages/stash/lib/libversion.py", line 52, in _parse_version
    verparts.append(int(v))
ValueError: invalid literal for int() with base 10: ''

[bennr01]

This is one of these issues that seem simple at first, but turn out to be extremely annoying. While the fix is not yet finished, here are some details regarding this issue (warning: slight rant):

Apparently, ics gave their first release the version indev. Since we want to find the newest release of a package, we must parse all versions first. This is normally not a problem because most packages use PEP440 conform versions. Spoiler: indev is not PEP440 compliant.

So, how should one handle this? After reading a bit more trough PEP440, it mandates that we should discard all versions following non-canonical versions. They are even so nice and provide a little regex to check if a version is canonical. So, simply check is a version matches the regex and discard it otherwise. Sounds simple, right?

Well, enter code-recycling. You see, there are various situation where we require extremely similar logic. For example, comparing the conditional requirements, for example extra-dependent requirements or python-version-dependent packages. And surprisingly, both of these cases broke after adding the canonical check.

The extra-dependent requirements are a simple case: since the foo part of extra == foo is not a version, it is not a canonical version.

The python-version dependent packages were more surprising. This is something I would not have noticed if it were not for our tests. You see, we test pip install against various packages of varying complexity. Among them is a package called twisted. Now, enter the follwing monstrosity: "requires_python": ">=2.7,!=3.0.*,!=3.1.*,!=3.2.*,!=3.3.*,!=3.4.*". So, where exactly is the problem? It is in the *, which is used for prefix based matching. First, the * is not valid in PEP440-canonical versions (they dont match the regex). This is only important due to some suboptimal formulations:

According to PEP345, which regulates the python-requires header, Version numbers must be in the format specified in Version Specifiers. and Each version number must be in the format specified in PEP 440.. This makes it sound like they must be PEP440 canonical. Well, apparently, PEP440 specifically allows versions with an asterisk, although they are non-canonical. Upon further examination, it appears that PEP345 didn’t mean the canonical versions which are the main topic of PEP440, but rather the very specific section Version matching. Looking back, it sounds obvious, but a better formulation would have made it easier to discern that they did not refer solely to the part of PEP440 containing the canonical versions.

Anyway, this is why you should always be explicit which part of a specification you are referring to, never make you parsers too lenient and should always follow PEP440-canonical versions.

[felciano]

@bennr01 yes I think you are likely right – seems like either a Pythonista issue or a sharesheet issue (or interaction between the two). But I think the command line test above indicates that the install worked via stash. I’ll migrate the rest of this to the forum. Thanks for your help!