brew-pip no longer works

[sorin-ionescu]

The following error occurs:

Error: undefined method `cached_location' for #<PipFormula::NoopDownloadStrategy:0x10db36790 @url="UNKNOWN">
Please report this bug:
    https://github.com/mxcl/homebrew/wiki/troubleshooting
/Users/sorin/.homebrew/Library/Homebrew/formula.rb:179:in `cached_download'
/Users/sorin/.homebrew/Library/Homebrew/formula.rb:616:in `fetch'
/Users/sorin/.homebrew/Library/Homebrew/formula.rb:641:in `stage'
/Users/sorin/.homebrew/Library/Homebrew/formula.rb:240:in `brew'
/Users/sorin/.homebrew/Library/Homebrew/build.rb:125:in `install'
/Users/sorin/.homebrew/Library/Homebrew/build.rb:43:in `main'
/Users/sorin/.homebrew/Library/Homebrew/build.rb:12
/var/folders/jp/qsb33jvx5hj6vv3zv3rhcgn00000gn/T/pygments.rb:23

The error is caused by formula.rb#L179 because class AbstractDownloadStrategy no longer defines the cached_download method. brew-pip extends AbstractDownloadStrategy to create its own download strategy.

brew-gem is also affected.

[mistydemeo]

Since you've found the source of this, I suggest you submit a pull request to brew-pip and brew-gem.

[sorin-ionescu]

@mistydemeo If cached_location is an always expected method that ought to be extended, it should be defined in AbstractDownloadStrategy.

[jacknagel]

Fixed in fc3cd4d

[sorin-ionescu]

@jacknagel brew-pip and brew-gem still don't work, because they don't implement the fetch and stage methods. Both are stale and have not been updated in two years. I could fork and fix the projects then update the formulas to point to my forks, or you can remove the brew-pip and brew-gem formulas from Homebrew.

[sorin-ionescu]

@jacknagel, the error now is the following:

Error: undefined method `file?' for nil:NilClass
Please report this bug:
    https://github.com/mxcl/homebrew/wiki/troubleshooting
/Users/sorin/.homebrew/Library/Homebrew/formula.rb:634:in `stage'
/Users/sorin/.homebrew/Library/Homebrew/formula.rb:232:in `brew'
/Users/sorin/.homebrew/Library/Homebrew/build.rb:132:in `install'
/Users/sorin/.homebrew/Library/Homebrew/build.rb:43:in `main'
/Users/sorin/.homebrew/Library/Homebrew/build.rb:12
/var/folders/jp/qsb33jvx5hj6vv3zv3rhcgn00000gn/T/pygments.rb:23

[jacknagel]

They already have stubs for fetch and stage or it would have failed at fetch rather than cached_location.

Anyway, we should just remove them. We've tried submitting patches for other issues before and they've been rejected.

[sorin-ionescu]

I think that they are useful. Like I have said, I could for fork the projects, fix them, then update the formulas to point to my forks.

[adamv]

Since these depend on implementation details of the Formula class, they should either be carried as Contributions, or ownership should be taken over.

[adamv]

I don't use them personally, so I don't have a strong opinion.

[sorin-ionescu]

@adamv There isn't much to do. One just has to fix them then fix them again when Homebrew diverges. brew-gem hasn't been updated in 2 years; it worked until the last few days.

[MikeMcQuaid]

If you can make a pull request to fix these that would be great, thanks.

[samueljohn]

For the brew-test-bot, we had a discussion how to automatically install python dependencies that are installable via pip. We could use brew-pip but then I suggest that we take ownership and reimplement brew-pip for this purpose.
After I am done with #18588 I have some free resources again.

[sorin-ionescu]

@samueljohn Both brew-pip and brew-gem are rudimentary and poorly written. They have fixed their author's itch but do not work reliably. While I got them to work, see my profile, I'm not happy with them. brew-pip ought to use virtualenv and brew-gem ought to use bundler, and they should just work without having the user adjust $PYTHONPATH, $GEM_HOME, and $GEM_PATH. They should always work no matter what virtualenv or rbenv is activated.

[samueljohn]

I don't really see the benefit of brew-pip any more at all when we (very soon) allow pip to install into $(brew --prefix)/bin and other improvements.

Therefore I vote to remove brew-pip once the Python 2.x and 3.x support has been pulled in.

The only benefit of brew-pip is that brew rm is possible (however brew upgrade was never really supported).

Installing into a virtualenv is another problem. Homebrew right now installs all python bindings into $(brew --prefix)/lib/python2.7/site-packages and having a virtualenv activated is not supported right now because the bindings often have to find the other libs and either hardcore these or use pythons default ctypes lookup. The latter will work with a brewed python because I will add the homebrew prefix to the search path (in case brew is not at /usr/local).

Within a virtualenv, DYLD_FALLBACK_PATH or something has to be set I guess in order to find the brewed .so files or .dylibs.
Also when building with pip, I patched (one is not yet pulled in) brewed python to have CFLAGS and LDFLAGS such that C extensions find brewed libs.

I am open to suggestions.
One I am finished with the mentioned improvements to python and pip, I will try to improve the situation with virtualenvs.

[sorin-ionescu]

Placing binaries in the brew /bin directory without the ability to easily remove them is a recipe for disaster. For this very reason I recommend not installing brew in /usr/local because everybody puts stuff there. I keep mine in ~/.homebrew.

I'm in favour of creating a new brew plugin called brew-egg since we are installing Python eggs; the method of installation, which seems to change quite often in the Python world, is not relevant. Such a plugin should support brew upgrade, brew info, brew home, and so on.

Is there no Ruby bundler equivalent in the Python world? I dislike that virtual environments have to be activated and deactivated. If one were to use virtual environments, wrapper scripts would have to be placed in /bin that would activate the virtual environment and execute the Python script in a subshell.

[MikeMcQuaid]

For this very reason I recommend not installing brew in /usr/local because everybody puts stuff there

A tangent but I wish you wouldn't recommend this. It means people don't get binaries.

[sorin-ionescu]

@MikeMcQuaid, yes, it's unfortunate that brew doesn't build relocatable binaries. Still, it's a bad path for brew. I've had native OS X packages corrupt the brew installation.

[MikeMcQuaid]

Brew does build relocatable binaries when it can. Most upstream software means it cannot.

[sorin-ionescu]

Is it not possible to test for and flag relocatable bottles to at least install some binaries?

On 31 May 2013, at 13:26, Mike McQuaid wrote:

Brew does build relocatable binaries when it can. Most upstream software means it cannot.

—
Reply to this email directly or view it on GitHub.

[MikeMcQuaid]

We already do.

[samueljohn]

Virtualenvs have quite a different use case. They are more for project specific encapsulation.

Something like bundler for python? I don't know. There is py2app and its not exactly the same (a often buggy,too because relocating is difficult).

I personally have a homebrew at /homebrew and 99% works. Some tools hard code to usr/local.

I am not sure if we shouldn't just trust pip for pure python packages. It's getting better with recent distutils in python 2.7.5.