-
Notifications
You must be signed in to change notification settings - Fork 69
Is latest v0.9.23 unsafe (like 0.9.22)? #566
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
I think the latest PySR version does use 0.9.23: https://github.com/MilesCranmer/PySR/blob/847fbc055f90e6b26f75fa1759e9bd8c8ff30b2c/requirements.txt I just like to be extra cautious since PythonCall is such an integral part of the package that has a large community of users, so I prefer to fix the version number for less commonplace dependencies (“less commonplace” = compared to numpy/pandas) |
It's still limited here in latest version and on master: https://github.com/MilesCranmer/PySR/blob/847fbc055f90e6b26f75fa1759e9bd8c8ff30b2c/environment.yml#L10 so I'm confused, not sure what that means, are either just suggestions? I'm not too familiar with these things in Python. [I think I understand now, one is for pip other for conda, and they are not used at the same time, so can "conflict", but I guess you forgot to update the other one...] I think you still basically answer that v0.9.23 is safe, or you think so, intend to use, not just with juliacall; I suppose you confirm (or assume) PythonCall.jl also safe at latest version. Are you concerned about 0.9.22, i.e. enough to think it (can and) should be retracted? |
Oh sorry, the environment.yml is out of date. It’s not used anywhere other than CI testing though (and as an example). requirements.txt is what actually gets uploaded to PyPI, and conda forge is built in a separate repo. |
@MilesCranmer I noticed that you avoid 0.9.22 (and that you're aware of 0.9.23):
MilesCranmer/PySR@ca7706e
If 0.9.23 is ok, then you may want to support it there, and was this an issue only for juliacall, or also PythonCall.jl?
I want to know mainly that latest version works for all users (not just you), and more about the hack to disable then enable GC. Is that something people need to be aware of or maybe outdated now?
I know packages can't be removed from the (Julia General) registry, but can't certain (older) versions be revoked? Is that needed here? That applies from the Julia side, and I'm not sure how things are handled from the Python side, pip, conda etc. So where might revoking be needed for Python packages, or would you way it's the responsibility of package authors (only) to avoid bad releases? It would not stop people to use non-latest of your package with the issue...
The text was updated successfully, but these errors were encountered: