search

conda-forge / jupyter_core-feedstock

A conda-smithy repository for jupyter_core.
BSD 3-Clause "New" or "Revised" License
2 stars 21 forks source link

install with pip #5

Closed minrk closed 8 years ago

minrk commented 8 years ago

Not for merge, yet.

Some debugging of Windows install not working, I'm guessing due to the wrong pip doing the installation.

conda-forge-linter commented 8 years ago

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

minrk commented 8 years ago

@ocefpaf I'm not sure what package is responsible, but I think I've narrowed it down to something conda is doing corrupting the .exe files produced by pip. I can pip install just fine and the commands work, but after conda packages them up, they are broken. Seems like a pretty severe bug in either conda or conda-build, I guess?

The failure is:

Fatal error in launcher: Unable to create process '"'

which I see when I RDC into the appveyor VM, but for some reason appveyor doesn't capture in the web view.

ocefpaf commented 8 years ago

Fatal error in launcher: Unable to create process '"'

Time to call @msarahan :wink:

msarahan commented 8 years ago

well, sadly, it's something of a bug between both conda and conda-build, and has taken patches to both to fix.

See more at https://github.com/conda/conda/pull/3224 and https://github.com/conda/conda-build/pull/1171

Long story short: If you build packages with conda-build >=1.21.11, they should have binary prefix replacement info in them. If you install these packages with conda >=4.2.3, that prefix should get fixed correctly.

Conda 4.2.3 has been tagged and should be available soon with conda update conda -c conda-canary

minrk commented 8 years ago

Great. I figured it out, but the issue seems unresolvable until conda starts working again.

I can pin 'pip < 7`, since 7.0 appears to be the version that introduced the change (over a year ago), but I cannot build on py35 because there was never a pip 6 package for py35.

My current plan is to hold off on updating any conda-forge packages until there's a working release of conda again.

msarahan commented 8 years ago

Can you enlighten me on why installation with pip is desirable? The only one I know of right now is that for setuptools entry points on Mac and Linux, you get reasonable scripts that don't depend on .pth files or pkg_resources. Are there other reasons we should think about using pip more generally? Does it enable specific functionality here?

I hope "hold off on updating any conda-forge packages until there's a working release of conda again" means holding off on changing to pip installs, not more generally avoiding updates - otherwise I feel like I've underestimated the magnitude of this issue. I'm confused as to how it became such a large issue, when I don't think that these entry points with pip have worked with conda since pip 6 (apparently).

minrk commented 8 years ago

I hope "hold off on updating any conda-forge packages until there's a working release of conda again" means holding off on changing to pip installs, not more generally avoiding updates

Since I'm already using pip in several conda-forge packages, I did mean that I won't be updating any packages until conda starts working again. However, since I now realize using conda entrypoints should be a satisfactory workaround while waiting for the pip entrypoints to resume working.

Can you enlighten me on why installation with pip is desirable?

I believe this has been discussed here, but the gist is that it is the only way to:

  1. guarantee that setuptools is used, and
  2. setuptools doesn't make a mess

The general goal is to ensure consistency of the behavior of the installed package. This is not accomplished if conda packages are built with raw distutils.

minrk commented 8 years ago

This PR now works, as long as the redundant conda-forge entrypoints are left in-place, instead of letting the pip entrypoints pass through.

ocefpaf commented 8 years ago

@minrk please correct me if I am wrong:

From a packager point of view the use of pip brings the advantage that we don't have to specify the entrypoints manually. And we to get the --single-version-externally-managed behavior for free even when setuptools is not used.

In light of those two advantages I believe we should move to pip install --no-deps . as soon as conda can handle it correctly. Until then specifying the entrypoints is not that big of a deal since we already have them there.

PS: @minrk do you want to merge this one or do you want to leave it open to wait for the new conda?

minrk commented 8 years ago

@ocefpaf good summary. I've merged this one since it works now, and we can back off the duplicate entrypoints when conda is fixed.

@msarahan sorry for my tone, I was pretty frustrated trying to figure out the right thing to do on this one, but I think the situation is fine, now.

msarahan commented 8 years ago

@minrk, no problem. I understand and share your frustration. I hope this all just works once conda >=4.2.3 is generally available.