gns3-gui
gns3-gui copied to clipboard
GNS3
Requirements.txt arch Linux versions greater than
Installing gns3 on arch Linux (from the aur) always has a problem as arch runs blessing edge versions of: jsonschema sentry-sdk psutil distro Originally I was trying to force these versions either on my system or a venv. However I am currently experimenting with just editing the requirements.txt (or requires.txt as installed on my system). I could patch the pkgbuild to make this change prior to install however would there be an issue in changing requirements.txt from:
jsonschema==3.2.0 sentry-sdk==1.9.5 psutil==5.9.1 distro==1.7.0
To
jsonschema>=3.2.0 sentry-sdk>=1.9.5 psutil>=5.9.1 distro>=1.7.0
Thanks for the consideration
Not sure why my code blocks were collapsed they should be on separate lines
The GNS3 dev team is not responsible for the AUR package. It is maintained by a third party.
Are you asking for something? Or looking for ideas to resolve the issue?
On Fri, Oct 7, 2022 at 20:22 bazzawill @.***> wrote:
Not sure why my code blocks were collapsed they should be on separate lines
— Reply to this email directly, view it on GitHub https://github.com/GNS3/gns3-gui/issues/3393#issuecomment-1272175067, or unsubscribe https://github.com/notifications/unsubscribe-auth/APZX5I3MTV2BIXSJGFAHK7LWCC5DHANCNFSM6AAAAAARAAH4IE . You are receiving this because you are subscribed to this thread.Message ID: @.***>
-- Ean L. Towne
@.***
I was asking if it was possible to patch this upstream rather than in the aur package. I.E. is it possible just to state the version of these packages must be equal or greater than rather than equal to. This could benefit more than just arch Linux users
On Sat, Oct 8, 2022, 11:32 AM eantowne @.***> wrote:
The GNS3 dev team is not responsible for the AUR package. It is maintained by a third party.
Are you asking for something? Or looking for ideas to resolve the issue?
On Fri, Oct 7, 2022 at 20:22 bazzawill @.***> wrote:
Not sure why my code blocks were collapsed they should be on separate lines
— Reply to this email directly, view it on GitHub https://github.com/GNS3/gns3-gui/issues/3393#issuecomment-1272175067, or unsubscribe < https://github.com/notifications/unsubscribe-auth/APZX5I3MTV2BIXSJGFAHK7LWCC5DHANCNFSM6AAAAAARAAH4IE
. You are receiving this because you are subscribed to this thread.Message ID: @.***>
-- Ean L. Towne
@.***
— Reply to this email directly, view it on GitHub https://github.com/GNS3/gns3-gui/issues/3393#issuecomment-1272184207, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAOSMJ4XUTIY2IAHUWL2N7TWCDBZXANCNFSM6AAAAAARAAH4IE . You are receiving this because you authored the thread.Message ID: @.***>
The GNS3 dev team is not responsible for the AUR package. It is maintained by a third party. Are you asking for something? Or looking for ideas to resolve the issue? On Fri, Oct 7, 2022 at 20:22 bazzawill @.> wrote: Not sure why my code blocks were collapsed they should be on separate lines — Reply to this email directly, view it on GitHub <#3393 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/APZX5I3MTV2BIXSJGFAHK7LWCC5DHANCNFSM6AAAAAARAAH4IE . You are receiving this because you are subscribed to this thread.Message ID: @.> -- Ean L. Towne @.***
I also use GNS3 on ArchLinux and the problem is not with the AUR package but with the fact that the GNS3 hardcodes the requirements to specific versions and when I update my system GNS3 does not start anymore because of a new package version.
I agree with @bazzawill statement.
The requirements should allow a minimum version and anything above at least on Linux since usually the newer version include bug fixes. It's true that major releases of packages in the requirements file could break functionality but it's very rare and it that case usually package maintainers take care of it.
I can understand, that der GNS3 devs (@grossmj) uses strict versions in the requirements, as that makes testing much simpler. Otherwise he needs to retest GNS3 everytime a dependency gets an update. On the other side, I agree that the need to install an older version of a package to fulfill the requirements is annoying.
What about a compromise: The mayor.minor version number is fixed, but the patch level may be higher. For example psutil==5.9.1 is replaced by psutil>=5.9.1,<5.10. That allows all 5.9.x, where x is >= 1. So small version changes in a package are fine, while larger changes are not allowed.
I can understand, that der GNS3 devs (@grossmj) uses strict versions in the requirements, as that makes testing much simpler.
Indeed! ;)
What about a compromise: The mayor.minor version number is fixed, but the patch level may be higher. For example psutil==5.9.1 is replaced by psutil>=5.9.1,<5.10. That allows all 5.9.x, where x is >= 1. So small version changes in a package are fine, while larger changes are not allowed.
This could work.
It should be noted we cannot upgrade some packages to their latest version because they dropped support for Python 3.6, we have dropped this version of Python as well in GNS3 v3.0 however we are still trying to support it in v2.x
In this case since these are 2 separate branches I think on 3.0 branch since it is the development version we can use the latest packages versions and for branch 2.x we can keep the fixed version to keep compatibility with Python 3.6 and maybe recommend users to upgrade to Python 3.7 version or higher.
I have prepared 2 PRs, well this not really pretty between supporting Python 3.6 and allowing for different dependencies at patch level, but it should work...
jsonschema>=4.16.0,<4.17; python_version >= '3.7'
jsonschema==3.2.0; python_version < '3.7' # v3.2.0 is the last version to support Python 3.6
aiohttp>=3.8.3,<3.9
aiohttp-cors>=0.7.0,<0.8
aiofiles>=22.1.0,<22.2; python_version >= '3.7'
aiofiles==0.8.0; python_version < '3.7' # v0.8.0 is the last version to support Python 3.6
Jinja2>=3.1.2,<3.2; python_version >= '3.7'
Jinja2==3.0.3; python_version < '3.7' # v3.0.3 is the last version to support Python 3.6
sentry-sdk==1.9.10,<1.10
psutil>=5.9.2,<5.10
async-timeout>=4.0.2,<4.1
distro>=1.7.0
py-cpuinfo>=8.0.0,<8.1
setuptools>=60.8.1; python_version >= '3.7'
setuptools==59.6.0; python_version < '3.7' # v59.6.0 is the last version to support Python 3.6
I think we are a bit being regarding dependency management, maybe we should consider something like poetry https://python-poetry.org/ or similar someday?