Conflict with JSON5 package

[Teej42]

@conda-forge/core

This was reported to me by the maintainer for ibm_db:

When you install this package on top of the JSON5 package, there will be a merge error on __init__.py file. This issue is not present when using pip. Details:

(base) phils-MBP:Downloads phil.downey$ conda install json5
Collecting package metadata (current_repodata.json): done
Solving environment: done

## Package Plan ##

environment location: //anaconda3

added / updated specs:
- json5

The following NEW packages will be INSTALLED:

json5 pkgs/main/noarch::json5-0.8.4-py_0

Proceed ([y]/n)? y

Preparing transaction: done
Verifying transaction: done
Executing transaction: done
(base) phils-MBP:Downloads phil.downey$ conda install -c conda-forge ibm_db
Collecting package metadata (current_repodata.json): done
Solving environment: done

## Package Plan ##

environment location: //anaconda3

added / updated specs:
- ibm_db

The following NEW packages will be INSTALLED:

ibm_db conda-forge/osx-64::ibm_db-3.0.1-py37h01d97ff_0

The following packages will be UPDATED:

ca-certificates pkgs/main::ca-certificates-2019.5.15-0 --> conda-forge::ca-certificates-2019.6.16-hecc5488_0

The following packages will be SUPERSEDED by a higher-priority channel:

certifi pkgs/main --> conda-forge
conda pkgs/main --> conda-forge
openssl pkgs/main::openssl-1.1.1c-h1de35cc_1 --> conda-forge::openssl-1.1.1c-h01d97ff_0

Proceed ([y]/n)? y

Preparing transaction: done
Verifying transaction: failed

ClobberError: The package 'conda-forge::ibm_db-3.0.1-py37h01d97ff_0' cannot be installed due to a
path collision for 'lib/python3.7/site-packages/tests/__init__.py'.
This path already exists in the target prefix, and it won't be removed by
an uninstall action in this transaction. The path appears to be coming from
the package 'defaults::json5-0.8.4-py_0', which is already installed in the prefix.

ClobberError: The package 'conda-forge::ibm_db-3.0.1-py37h01d97ff_0' cannot be installed due to a
path collision for 'lib/python3.7/site-packages/tests/__pycache__/__init__.cpython-37.pyc'.
This path already exists in the target prefix, and it won't be removed by
an uninstall action in this transaction. The path appears to be coming from
the package 'defaults::json5-0.8.4-py_0', which is already installed in the prefix.

CondaVerificationError: The package for ibm_db located at //anaconda3/pkgs/ibm_db-3.0.1-py37h01d97ff_0
appears to be corrupted. The path 'lib/python3.7/site-packages/clidriver/db2dump/._db2diag.log'
specified in the package manifest cannot be found.

How exactly should we address this?

Thanks.

[isuruf]

Add a rm -rf $SP_DIR/tests to the build script on both packages.

[ocefpaf]

Add a rm -rf $SP_DIR/tests to the build script on both packages.

Yep. Looks like both packages are shipping a module named tests. That can be worked around like @isuruf mentioned but, ideally, it should be fixed upstream.

Also, it is odd that pip does not warm about overwriting that module. I guess that the last on installed wins?

[SabaKauser]

@ocefpaf pip copies the files to tests folder. init.py is an empty file and pose no problem and other test files are copied into the tests folder as is retaining the ones from earlier installations.

[SabaKauser]

Add a rm -rf $SP_DIR/tests to the build script on both packages.

@isuruf , I think conda-forge should not error out. There are numerous packages with tests folder in them and having to fail installation is not a good idea. The behavior we currently have in pip is better and no problems seen or reported from users so far. A warning that tests folder already exist sounds better, along with copying the files recursively.

[ocefpaf]

@ocefpaf pip copies the files to tests folder. init.py is an empty file and pose no problem and other test files are copied into the tests folder as is retaining the ones from earlier installations.

Quite messy!

@isuruf , I think conda-forge should not error out.

It is not conda-forge, it is conda. And it should error out. We cannot have a hybrid module named tests that has everything that other packages can copy into it. If someone claims the name tests for a package this would break that package. In the best case scenario this breaks these packages tests.

There are numerous packages with tests folder in them and having to fail installation is not a good idea.

It is. The packages are broken and should not ship a module named tests.

The behavior we currently have in pip is better and no problems seen or reported from users so far.

Nope. That is quite dangerous!