Closed emilkeyder closed 5 years ago
Thanks Emil - Now that we raise a TypeError
each time a term is tried to use within some associative container, it is instructive to see how many buggy such uses of terms we had in our own code... !
Thanks for the quick fix. Is there any way I can subscribe to the pypi releases so I know when there is a new release pushed to try in my system?
Good question - I have never seen anything like that, but it seems there's a few not-so-direct ways of doing that: https://stackoverflow.com/questions/17395151/how-can-i-subscribe-to-updates-of-a-package-on-pypi.
That said, at the moment we don't have a clear/strict policy on when to update new releases to pypi. Ideally we'd want to automatically package&publish each new bugfix release, but we're not there yet. You can however install from the github repo instead of pypi, e.g. as in:
pip install -U git+https://github.com/aig-upf/tarski.git
Or use these git-based handles on your requirements.txt
or setup.py
, and then simply pip install --upgrade
or similar. This way you'd stay up-to-date with the master branch even if we don't push the changes to pypi.
Worry with that is that there's a potential for build breakage every time there's a new push, so ideally I would like to only pull big releases/be able to pin the version after testing it. I will monitor the releases and do some manual testing before switching from our local version to the pypi version that incorporates this fix once it is available. Thanks!
If this helps, you can also pin down a particular commit ID from the repo to avoid the problem you're describing, and update that ID only when desired. This is e.g. the relevant portion of the setup.py
of one of my projects using Tarski:
setup(
name='basilisk',
# ...
install_requires=[
"tarski @ git+ssh://git@github.com/aig-upf/tarski.git@8ab6321",
],
)
If that doesn't work let me know and I'll push the new version to pypi, it's just 5 minutes ;-)
(Forgot to mention, but there's similary syntax for requirements.txt
-based projects.)
Ah yeah, think I actually did that before but then forgot about it... I'll give it a try, thanks again.
Just for the record, the newly-uploaded version 0.3.0
includes this bugfix along with other features and bugfixes.
When print_instance receives a non-None constant_objects argument, it tries to create a set of Constants here:
https://github.com/aig-upf/tarski/blob/master/src/tarski/io/fstrips.py#L181
this fails because class Constant has
hash()
defined but not__hash__()
.