Skip to content
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

developer install currently broken on macOS #1497

Closed
kosack opened this issue Oct 28, 2020 · 8 comments
Closed

developer install currently broken on macOS #1497

kosack opened this issue Oct 28, 2020 · 8 comments

Comments

@kosack
Copy link
Contributor

kosack commented Oct 28, 2020

Using a clean install of miniconda (or anaconda), and following the install instructions fails for both python 3.7 and 3.8 with an error of Found conflicts! Looking for incompatible packages.. Seems there is a missing package or too-strict dependency somewhere for macOS, since this works fine for Linux.

We used to test installs on macOS in Travis - why did that stop?

steps to reproduce:

PYTHON_VERSION=3.7 sed -i -e "s/- python=.*/- python=$PYTHON_VERSION/g" environment.yml
conda env create -n ctadev --file environment.yml
@maxnoe
Copy link
Member

maxnoe commented Oct 28, 2020

At some point the build did not work and we removed it.

@kosack
Copy link
Contributor Author

kosack commented Oct 28, 2020

At some point the build did not work and we removed it.

since many of the devs (myself included) use macOS, we should think about fixing that.

@kosack
Copy link
Contributor Author

kosack commented Oct 28, 2020

Seems simply adding conda-forge to the channel list fixes it. So I guess using - conda-forge::<PACKAGE> tries to get a single package from conda-forge, but not its dependencies, leading to no solution during dependency resolution

# A conda environment with all useful package for ctapipe developers
name: cta-dev
channels:
  - default
  - conda-forge
  - cta-observatory
...

@maxnoe
Copy link
Member

maxnoe commented Oct 28, 2020

@kosack that seems to be it.

By the way, I learned today that astropy imports their conda-forge packages to the astropy namespace, so that people don't have to solve vs. the full conda forge.

We could do the same.

@maxnoe
Copy link
Member

maxnoe commented Oct 28, 2020

Wenn we add the conda-forge channel, now suddenly everything comes from forge. Do we want that?

That for example means no mkl

@kosack
Copy link
Contributor Author

kosack commented Oct 28, 2020

By the way, I learned today that astropy imports their conda-forge packages to the astropy namespace, so that people don't have to solve vs. the full conda forge.

That's an option, since requiring everything from conda-forge is maybe not the best idea. It means some more maintenance for us though, since I guess they have to move packages to their channel.

There must be some way to keep the basic packages in defaults like numpy MKL, and still use a few packages from conda-forge. Not sure why the deps are so restrictive now.

@maxnoe
Copy link
Member

maxnoe commented Oct 28, 2020

For now you can probably simply add conda-forge::corsikaio, does that solve you problem?

@maxnoe
Copy link
Member

maxnoe commented Feb 12, 2021

I think this was fixed? @kosack can you confirm?

maxnoe added a commit that referenced this issue Feb 12, 2021
@kosack kosack closed this as completed in 5669160 Feb 12, 2021
nbiederbeck pushed a commit to nbiederbeck/ctapipe that referenced this issue Feb 16, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants