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
Create show_versions.py #9144
Create show_versions.py #9144
Conversation
Can one of the admins verify this patch? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @SultanOrazbayev! Overall this looks like things are moving in the right direct
Instead of adding a new module, could you just add show_versions
to dask/utils.py
? This is a relatively small utility that I don't think merits its own module
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Weird issue, but I tried this out locally and it is giving a different version than dask.__version__
In [1]: import dask
...: from dask.utils import show_versions
In [2]: show_versions()
{
"Python": "3.9.10",
"Platform": "Linux",
"dask": "2022.4.0",
"distributed": "2022.4.0",
"numpy": "1.22.3",
"pandas": "1.4.2",
"cloudpickle": "2.0.0",
"fsspec": "2022.1.0",
"bokeh": "2.4.2",
"fastparquet": "0.8.0",
"pyarrow": "6.0.1",
"zarr": "2.10.3"
}
In [3]: dask.__version__
Out[3]: '2022.05.2+10.g0b9963154.dirty'
This seems to be due to running it from a folder that contains |
I get that result in my dev env no matter where I run it from. It could be something about using |
I'll try to reproduce, are you using codespaces for this by any chance?(trying to make sure I get a similar setup) |
This is just in an ipython or python prompt in my terminal. The conda env that I have activated was created according to the developer guide (https://docs.dask.org/en/stable/develop.html#development-environment) |
Here's what I did to reproduce: git clone git@github.com:SultanOrazbayev/dask.git
cd dask
conda env create -n dask-dev -f continuous_integration/environment-3.9.yaml
# a few moments later
conda activate dask-dev Now, let's compare the python -c 'from importlib.metadata import version; print(version("dask"))'
# 2022.5.2
python -c 'import dask; print(dask.__version__)'
# 2022.05.2+6.g56eeb0610 To check that this is due to module search problem, let's quickly test in some nested directory: mkdir test_directory
cd test_directory
python -c 'import dask; print(dask.__version__)'
# 2022.05.2
python -c 'from importlib.metadata import version; print(version("dask"))'
# 2022.5.2
# clean-up
cd .. && rm -vr test_directory So I can definitely reproduce this problem without getting to (edit: sorry had to repost the comment due to copy-paste error) |
Can't we just do |
@SultanOrazbayev have you had the chance to look at what Julia suggested in the comment above? |
@ncclementi Yes, Julia's suggestion will work... I wasn't sure if that's the way to proceed, though. (no particular reservations, just not sure if there's a 'best practice' to deal with this, as it seems different projects handle it differently...) If that's the preferred way forward, kindly confirm and I will change the code to use |
@jsignell since you made the suggestion to go with |
I think for dask and distributed we should feel free to use |
Now dask and distributed use python -c 'import dask; print(dask.__version__)'
# 2022.05.2+11.g4091fba32
python -c 'import dask; dask.utils.show_versions()'
# {
# "Python": "3.10.4",
# "Platform": "Linux",
# "dask": "2022.05.2+11.g4091fba32",
# "distributed": "2022.5.2",
# "numpy": "1.22.3",
# "pandas": "1.4.2",
# "cloudpickle": "2.1.0",
# "fsspec": "2022.5.0",
# "bokeh": "2.4.3",
# "fastparquet": null,
# "pyarrow": null,
# "zarr": null
# } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks great! Thanks @SultanOrazbayev for sticking with this!
pre-commit run --all-files
For now the import is not integrated into
__init__.py
, not sure if that's feasible/reasonable.