You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The version constraint == will introduce the risk of dependency conflicts because the scope of dependencies is too strict.
The version constraint No Upper Bound and * will introduce the risk of the missing API Error because the latest version of the dependencies may remove some APIs.
After further analysis, in this project,
The version constraint of dependency batinfo can be changed to >=0.3,<=0.4.2.
The version constraint of dependency feedparser can be changed to >=6.0.0b1,<=6.0.10.
The version constraint of dependency geocoder can be changed to >=0.7.3,<=1.38.1.
The version constraint of dependency Pillow can be changed to ==9.2.0.
The version constraint of dependency Pillow can be changed to >=2.0.0,<=9.1.1.
The version constraint of dependency pylast can be changed to >=1.1.0,<=5.0.0.
The version constraint of dependency pytz can be changed to >=2011d,<=2013d.
The version constraint of dependency pytz can be changed to >=2011b,<=2022.1.
The version constraint of dependency twython can be changed to >=1.3,<=1.4.3.
The version constraint of dependency twython can be changed to >=1.4.5,<=2.7.3.
The version constraint of dependency twython can be changed to >=3.0.0,<=3.9.1.
The above modification suggestions can reduce the dependency conflicts as much as possible,
and introduce the latest version as much as possible without calling Error in the projects.
The invocation of the current project includes all the following methods.
The version constraint == will introduce the risk of dependency conflicts
However, there is no such constraint in the list you've cited.
The version constraint No Upper Bound and * will introduce the risk of the missing API Error because the latest version of the dependencies may remove some APIs.
True. However, not having an upper bound introduces the risk of not having the latest security bugfixes. I personally prefer bug and security fixes over API risk. Why do you prefer potentially open security issues and introducing upper bounds?
For the same reason, I don't understand why I should limit versions for batinfo and more you've provided. Furthermore, since many Memacs modules were contributed by others, I'm not able to decide or check any of those dependencies on my own.
Hi, In Memacs, inappropriate dependency versioning constraints can cause risks.
Below are the dependencies and version constraints that the project is using
The version constraint == will introduce the risk of dependency conflicts because the scope of dependencies is too strict.
The version constraint No Upper Bound and * will introduce the risk of the missing API Error because the latest version of the dependencies may remove some APIs.
After further analysis, in this project,
The version constraint of dependency batinfo can be changed to >=0.3,<=0.4.2.
The version constraint of dependency feedparser can be changed to >=6.0.0b1,<=6.0.10.
The version constraint of dependency geocoder can be changed to >=0.7.3,<=1.38.1.
The version constraint of dependency Pillow can be changed to ==9.2.0.
The version constraint of dependency Pillow can be changed to >=2.0.0,<=9.1.1.
The version constraint of dependency pylast can be changed to >=1.1.0,<=5.0.0.
The version constraint of dependency pytz can be changed to >=2011d,<=2013d.
The version constraint of dependency pytz can be changed to >=2011b,<=2022.1.
The version constraint of dependency twython can be changed to >=1.3,<=1.4.3.
The version constraint of dependency twython can be changed to >=1.4.5,<=2.7.3.
The version constraint of dependency twython can be changed to >=3.0.0,<=3.9.1.
The above modification suggestions can reduce the dependency conflicts as much as possible,
and introduce the latest version as much as possible without calling Error in the projects.
The invocation of the current project includes all the following methods.
The calling methods from the batinfo
The calling methods from the feedparser
The calling methods from the geocoder
The calling methods from the Pillow
The calling methods from the pylast
The calling methods from the pytz
The calling methods from the twython
The calling methods from the all methods
@developer
Could please help me check this issue?
May I pull a request to fix it?
Thank you very much.
The text was updated successfully, but these errors were encountered: