add info about system requirements #73
Labels
No Label
bug
compatibility
documentation
duplicate
enhancement
future release
help wanted
invalid
non-code
question
refactor
testing
this release
wontfix
No Milestone
No Assignees
3 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: cmccabe/linkulator2#73
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
I got a first user report that linkulator doesn't run on systems with versions of Python older than 3.5 or maybe 3.6. Is there any type of code scanner that will report on the system requirements of a program like linkulator, or do we just need to make our best guess based on knowing which libraries we've used?
I dont know of an automated tool. I always think a language will have one available but I am never able to find them. I really wanted one for Go when working on Bombadillo so that I didnt use too new of language features (
make test
helps... when I remember to run it, doh!).You could try running on a bunch of versions but that is annoying. Do you know the version the user was running? There was an early 3.x series release that I know had some compatibility issues in general, maybe 3.3?
It was Python 3.4, on Zaibatsu.
I think you have to check against each version. The Tox documentation first page shows how that tool can be used to run tests in multiple virtual environments, which would hopefully pick up compatibility issues.
On the systems where this is coming up, is
python3
actually the newest version available? For example, on my systempython3 --version
shows 3.7.5, but I also havepython3.8
available. I think the shebang could be adjusted in this case from python3 to python3.8.It would be worthwhile to have a minimum version we write for, although I'm not sure what that should be. For Bombadillo, I think the aim was to keep compatibility with the latest Debian stable, based on feedback from creme.
Zaibatsu is running Debian 8, which only has Python 3.4 in its main repo.
Targeting Debian stable seems like a reasonable choice. In general, that is a fairly conservative target so we shouldn't lose too many people. Buster currently supports Python 3.7.
I have installed Tox on rawtext.club. Now to try it out!
I'd be interested to know what features or libs we are running into that are not compatible with 3.4. My guess would be that the funcitonality provided by them should be easily replicable via other means. That was the case every time I ran into version issues for Bombadillo.
This is the error I see when running it on Zaibatsu. I'm not sure what this syntax is called.
Oh. Interesting. I am not familiar with that syntax either. What is that doing? Is it some form of type hinting or something?
The error you are seeing is from type hinting, similar to #75. There are likely other compatibility issues, so it would be a good idea to investigate at a low version to understand this better.
Non-compatible features like typing could be removed. Alternative approaches are to package the requirements with the application. I think this means something like packaging Python 3.8 with the application (?), or using backported libraries.
Any of these topics require further investigation. 3.4 is the lowest version I've seen reported, and seems like it will be supported until mid-year, so perhaps we can start there. @cmccabe if you want to target a specific version, I'm happy to go with your choice.
If it is simple type hinting I think we could likely use duck typing to avoid needing to take advantage of newer language based type hinting features. I do not recall seeing type hinting in python before and I used the earlier versions quite a bit, but I may have just missed it.
I have oft complained about php's type hinting. I have always felt like if you are reaching for type hinting in a language that is not strongly typed then you are using the wrong language for the task at hand. But that is just one persons opinion, lol.
3.4 seems like a good target version. It is early enough to get most users.
Tox is used to do things like lint or run tests in multiple versions of Python, with isolation for each version. It works pretty well, but is mainly to streamline the process.
The actual per-version testing seems to require each version is installed/available. My system package manager doesn't go lower than 3.7. I've tried pyenv to get access to older verions, and this seems to work well. The downside is that it downloads and compiles each version of Python it installs, and 3.4 fails on my system.
I'm not sure if there is an easier way to do this, but would welcome any suggestions.
I was able to look at 3.5.3, these are the issues I've found so far:
LinkDataRecord
, the data structure at the basis of adding posts and replies to the database.open()
function (and other os and os.Path functions) to interpret Pathlib path objects. Paths have to be converted to strings before use.So far, fixing this means redoing adding posts/replies, and validating all operations using path objects. There could be other unseen issues beyond this.
The good news is that it seems we are compatible with Python 3.6.
Just a further note from my PR #85 - I've aimed to:
A couple of bummers:
I think this PR can address most of this issue. Compatibility with 3.4 would be the only outstanding item.