Can one of the admins verify this patch?

This seems to be due to running it from a folder that contains dask (re: module search path). Not sure if this exception should be handled explicitly...

This seems to be due to running it from a folder that contains dask (re: module search path). Not sure if this exception should be handled explicitly...

I get that result in my dev env no matter where I run it from. It could be something about using pip install -e I suppose. But yes it would be very good to figure out what's going on and handle it explicitly.

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 importlib.metadata and dask.__version__:

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 pip install -e . step. How to tackle this situation? Would checking if there is a folder with name dask and __init__.py in it be sufficient?

(edit: sorry had to repost the comment due to copy-paste error)

Can't we just do from dask import __version__ and use that? I looked at what bokeh is doing in their info command and it looks like that is what they are doing:

https://github.com/bokeh/bokeh/blob/fb1a54cd1852b762d948a76e9dec79f6b1edf89e/bokeh/command/subcommands/info.py#L125-L132

@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 __version__ approach.

@jsignell since you made the suggestion to go with from dask import __version__ what do you think about Sultan's comment above? Should we go with this approach?

I think for dask and distributed we should feel free to use __version__ that will definitely not be going anywhere and it's important to get those versions right!

Now dask and distributed use __version__, the whiteline between the imports looks odd, but that's what black/isort did. Here are the outputs I get:

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
# }