add info about system requirements #73

Open
opened 2020-01-14 14:55:56 +00:00 by cmccabe · 11 comments
Owner

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 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?
Collaborator

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?

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?
sloum added the
question
label 2020-01-14 19:33:11 +00:00
Author
Owner

It was Python 3.4, on Zaibatsu.

It was Python 3.4, on Zaibatsu.
Collaborator

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 system python3 --version shows 3.7.5, but I also have python3.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.

I think you have to check against each version. The [Tox documentation](https://tox.readthedocs.io/en/latest/) 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 system `python3 --version` shows 3.7.5, but I also have `python3.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.
Author
Owner

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!

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!
Collaborator

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.

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.
Author
Owner

This is the error I see when running it on Zaibatsu. I'm not sure what this syntax is called.

cmccabe@circumlunar:~/testing/linkulator2$ ./linkulator.py 
  File "./linkulator.py", line 21
    link_data: list = LinkData.link_data
             ^
SyntaxError: invalid syntax
This is the error I see when running it on Zaibatsu. I'm not sure what this syntax is called. ``` cmccabe@circumlunar:~/testing/linkulator2$ ./linkulator.py File "./linkulator.py", line 21 link_data: list = LinkData.link_data ^ SyntaxError: invalid syntax ```
Collaborator

Oh. Interesting. I am not familiar with that syntax either. What is that doing? Is it some form of type hinting or something?

Oh. Interesting. I am not familiar with that syntax either. What is that doing? Is it some form of type hinting or something?
sloum added this to the Sys Requirements Issue milestone 2020-01-16 18:42:58 +00:00
sloum added the
compatibility
documentation
labels 2020-01-16 18:53:12 +00:00
Collaborator

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.

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](https://pypi.org/project/typing/). 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](https://www.debian.org/releases/jessie/), so perhaps we can start there. @cmccabe if you want to target a specific version, I'm happy to go with your choice.
Collaborator

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.

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.
Collaborator

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:

  • Typing of objects is not available, including the class typing on LinkDataRecord, the data structure at the basis of adding posts and replies to the database.
  • There's no support for the file 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.

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: - Typing of objects is not available, including the class typing on `LinkDataRecord`, the data structure at the basis of adding posts and replies to the database. - There's no support for the file `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.
Collaborator

Just a further note from my PR #85 - I've aimed to:

  • ensure the minimum version is documented
  • ensure we can test each version we support

A couple of bummers:

  • Testing each version means installing them somehow, but have not provided advice on this as I think it's out of scope. If anyone wants to know how I do this with pyenv, feel free to reach out.
  • I couldn't find a way to get the version check code added by @cmccabe working. I really like this idea, but we would need a way to handle the syntax error.

I think this PR can address most of this issue. Compatibility with 3.4 would be the only outstanding item.

Just a further note from my PR #85 - I've aimed to: - ensure the minimum version is documented - ensure we can test each version we support A couple of bummers: - Testing each version means installing them somehow, but have not provided advice on this as I think it's out of scope. If anyone wants to know how I do this with pyenv, feel free to reach out. - I couldn't find a way to get the version check code added by @cmccabe working. I really like this idea, but we would need a way to handle the syntax error. I think this PR can address most of this issue. Compatibility with 3.4 would be the only outstanding item.
Sign in to join this conversation.
No description provided.