librelist archives

Re: [homebrew] Removal of PIP/Distribute

From:

Adam Vandenberg

Date:

2011-03-21 @ 05:03

("pip install numpy" works against a non-Framework version.)

For doing Py2App stuff, it is probably a much better idea to use an
official Python OS X installer for the Framework build, rather than
custom-compile.
Is there a reason to want to custom-compile Python when writing apps
for distribution, rather than using the provided downloader for 2.7.1?

On Sun, Mar 20, 2011 at 9:48 PM, Kenneth Reitz <me@kennethreitz.com> wrote:
> A number of modules  (particularly with a c-heavy codebase) expect a
> framework installation of Python on OS X.
> It was a stumbling block at first when i first migrated to homebrew's
> python. Switching to the --framework build solved all of my build problems.
> Off the top of my head:
> - py2app / pyinstaller
> - NumPy maybe?
> I'd have to sit down to compile an accurate list. I might be wrong on those.
> MacPorts and the installer from Python.org provide framework builds, as well
> as OSX out of the box.
> Homebrew seems to be the only popular installation method that doesn't
> default a framework build. Is there a benefit of using a unix-style build?
>
> --
> Kenneth Reitz
> http://ken nethreitz.com/contact-me
>
> On Monday, March 21, 2011 at 12:40 AM, Adam Vandenberg wrote:
>
> What compatibility issues have you run into having a non-Framework
> Python 2.7.1 installed?
>
> On Sun, Mar 20, 2011 at 9:39 PM, Kenneth Reitz <me@kennethreitz.com> wrote:
>
> Adam, could you briefly tell me why --framework isn't default?
> I think enabling it by default would help alleviate a number of
> compatibility issues.
> --
> Kenneth Reitz
> http://kennethreitz.com/contact-me
>
> On Monday, March 21, 2011 at 12:34 AM, Adam Vandenberg wrote:
>
> I've updated the Wiki page:
> https://github.com/mxcl/homebrew/wiki/Homebrew-and-Python
> and squashed the commits in my branch:
> https://github.com/adamv/homebrew/commit/308dc7a1a4d64adc6f
> 457702ba30bd300944964b
>
> Any feedback is greatly appreciated; I want to make sure this change
> is solid before merging into trunk.
>
> On Sun, Mar 20, 2011 at 5:26 PM, Lee Packham <lpackham@leenux.org.uk> wrote:
>
> Looks good - thanks for adding Distribute back.
> On Monday, 21 March 2011 at 00:15, Adam Vandenberg wrote:
>
> Ah, right, Python would not yet have been linked from Cellar to Prefix.
> New commit:
> 
https://github.com/adamv/homebrew/commit/4f42b84c451aba6c63f0ec090bcd617c9a2dd521
>
>
> On Sun, Mar 20, 2011 at 5:08 PM, Kenneth Reitz <me@kennethreitz.com> wrote:
>
> Still not working..
> /usr/local/bin/ doesn't contain python for some reason.
> Also, the distribute installation tries to run `/usr/local/python setup.py
> install`
> --
> Ken neth Reitz
> http://kennethreitz.com/contact-me
>
> On Sunday, March 20, 2011 at 7:27 PM, Kenneth Reitz wrote:
>
> Thanks. Installing now.
> Any feedback on why --framework isn't default?
>
> --
> Kenneth Reitz
> http://kennethreitz.com/contact-me
>
> On Sunday, March 20, 2011 at 7:26 PM, Adam Vandenberg wrote:
>
> Should be fixed here:
> 
https://github.com/adamv/homebrew/commit/e7ca0ac365a913cd576c8cc47a1ec3cb1a79d463
>
> On Sun, Mar 20, 2011 at 4:23 PM, Kenneth Reitz <me@kennethreitz.com> wrote:
>
> Actually the distribute installation failed because it ran against my system
> python (oops!).
>
>
> --
> Kenneth Reitz
> http://kennethreitz.com/contact-me
> On Sunday, March 20, 2011 at 7:20 PM, Kenneth Reitz wrote:
>
> Excellent. I just ran this formula and it set up everything perfectly.
> I *really* think framework should enabled by default though.
> --
> Kenneth Reitz
> http://kennethreitz.com/contact-me
>
> On Sunday, March 20, 2011 at 7:13 PM, Adam Vandenb erg wrote:
>
> Also note that the changes in the first commit allow "python setup.py
> install" to "just work" now, without having to pass in any particular
> paths on switches.
>
> On Sun, Mar 20, 2011 at 4:12 PM, Adam Vandenberg <flangy@gmail.com> wrote:
>
> Please review top 2 commits here:
> https://github.com/adamv/homebrew/commits/python
>
> I'm willing to let the Python formula install distribute automatically
> due to the path changes in the first commit.
> Since site-packages/ install-scripts live outside of the Cellar and in
> the Prefix, updates to Python won't nuke these things like the 2.7.0
> to 2.7.1 update did.
>
> The pack-in distribute can itself be updated without rebrewing python by
> doing:
>
> $ easy_install pip
> $ pip install --upgrade distribute
>
>
> On Sun, Mar 20, 2011 at 1 :24 PM, Charlie Sharpsteen
> <chuck@sharpsteen.net> wrote:
>
> +1 here as well, we need access to `easy_install`.
> On Sun, Mar 20, 201 1 at 1:09 PM, Kenneth Reitz <me@kennethreitz.com> wrote:
>
> Agreed. Distribute is essential. I'm more than happy to install pip myself
> w/ it.
>
> --
> Kenneth Reitz
> http://kennethreitz.com/contact-me
>
> On Sunday, March 20, 2011 at 4:05 PM, Lee Packham wrote:
>
> Copied from GH-4226 as more people read the mailing list than tickets:
>
> I fe el this change is a deal breaker for me with regards to doing Python
> development on OSX. This just shifts the pain and, imho, makes things
> harder. I knew when upgrading python I just had to rebrew a couple of items
> and install things I had (which is fine with pip as you can use a text file
> for input).
>
> Using things like virtualenv-burrito solves little as you still have to
> update virtualenv's every time you upgrade python anyway.
>
> At least keep distribute. From distribute it's easy to install p ip. All
> this change does is cripples Python in homebrew. Might as well just take
> Python out entirely.
>
> Sorry if this sounds so negative - I just feel very strongly that this is
> a bad move.
>
> Regards,
>
> Lee Packham
>
>

On 21 March 2011 00:03, Adam Vandenberg <flangy@gmail.com> wrote:
> ("pip install numpy" works against a non-Framework version.)
>
> For doing Py2App stuff, it is probably a much better idea to use an
> official Python OS X installer for the Framework build, rather than
> custom-compile.
> Is there a reason to want to custom-compile Python when writing apps
> for distribution, rather than using the provided downloader for 2.7.1?

I don't know huge amounts about Python in Homebrew but my opinion is
the defaults should match upstream/OSX-native as closely as possible.

-- 
Mike McQuaid
http://mikemcquaid.com

I agree with Mike. Why is homebrew defaulting to a non-framework build 
when it's an established standard? 

Confirmed:

- sip requires Framework build
- pyobjc requires Framework build

Are there any benefits of using a unix-style build?


http://stackoverflow.com/questions/1444543/differences-between-framework-and-non-framework-builds-of-python-on-mac-os-x

-- 
Kenneth Reitz
http://kennethreitz.com/contact-me
On Monday, March 21, 2011 at 11:25 AM, Mike McQuaid wrote: 
> On 21 March 2011 00:03, Adam Vandenberg <flangy@gmail.com> wrote:
> > ("pip install numpy" works against a non-Framework version.)
> > 
> > For doing Py2App stuff, it is probably a much better idea to use an
> > official Python OS X installer for the Framework build, rather than
> > custom-compile.
> > Is there a reason to want to custom-compile Python when writing apps
> > for distribution, rather than using the provided downloader for 2.7.1?
> 
> I don't know huge amounts about Python in Homebrew but my opinion is
> the defaults should match upstream/OSX-native as closely as possible.
> 
> -- 
> Mike McQuaid
> http://mikemcquaid.com
> 

I'm all for a framework build, it's just the upgrade path from 
non-framework to framework could be a little painful for some.
On Monday, 21 March 2011 at 15:33, Kenneth Reitz wrote: 
> I agree with Mike. Why is homebrew defaulting to a non-framework build 
when it's an established standard? 
> 
> Confirmed:
> 
> - sip requires Framework build
> - pyobjc requires Framework build
> 
> Are there any benefits of using a unix-style build?
> 
> 
http://stackoverflow.com/questions/1444543/differences-between-framework-and-non-framework-builds-of-python-on-mac-os-x
> 
> -- 
> Kenneth Reitz
> http://kennethreitz.com/contact-me
> On Monday, March 21, 2011 at 11:25 AM, Mike McQuaid wrote:
> > On 21 March 2011 00:03, Adam Vandenberg <flangy@gmail.com> wrote:
> > > ("pip install numpy" works against a non-Framework version.)
> > > 
> > > For doing Py2App stuff, it is probably a much better idea to use an
> > > official Python OS X installer for the Framework build, rather than
> > > custom-compile.
> > > Is there a reason to want to custom-compile Python when writing apps
> > > for distribution, rather than using the provided downloader for 2.7.1?
> > 
> > I don't know huge amounts about Python in Homebrew but my opinion is
> > the defaults should match upstream/OSX-native as closely as possible.
> > 
> > -- 
> > Mike McQuaid
> > http://mikemcquaid.com
> 

Now's the time to do it since pip is being removed and distribute's 
installing things outside of the Cellar. 

Before, every time I updated Python, I had to reinstall all of my modules.
Since that will no longer be an issue when Adam's patch is pushed to 
mxcl's repo, if it's going to happen, it should happen now. 
-- 
Kenneth Reitz
http://kennethreitz.com/contact-me
On Monday, March 21, 2011 at 11:36 AM, Lee Packham wrote: 
> I'm all for a framework build, it's just the upgrade path from 
non-framework to framework could be a little painful for some.
> On Monday, 21 March 2011 at 15:33, Kenneth Reitz wrote: 
> > I agree with Mike. Why is homebrew defaulting to a non-framework build
when it's an established standard? 
> > 
> > Confirmed:
> > 
> > - sip requires Framework build
> > - pyobjc requires Framework build
> > 
> > Are there any benefits of using a unix-style build?
> > 
> > 
http://stackoverflow.com/questions/1444543/differences-between-framework-and-non-framework-builds-of-python-on-mac-os-x
> > 
> > -- 
> > Kenneth Reitz
> > http://kennethreitz.com/contact-me
> > On Monday, March 21, 2011 at 11:25 AM, Mike McQuaid wrote:
> > > On 21 March 2011 00:03, Adam Vandenberg <flangy@gmail.com> wrote:
> > > > ("pip install numpy" works against a non-Framework version.)
> > > > 
> > > > For doing Py2App stuff, it is probably a much better idea to use an
> > > > official Python OS X installer for the Framework build, rather than
> > > > custom-compile.
> > > > Is there a reason to want to custom-compile Python when writing apps
> > > > for distribution, rather than using the provided downloader for 2.7.1?
> > > 
> > > I don't know huge amounts about Python in Homebrew but my opinion is
> > > the defaults should match upstream/OSX-native as closely as possible.
> > > 
> > > -- 
> > > Mike McQuaid
> > > http://mikemcquaid.com
> 

If we were to do that (match upstream/OSX-native) then we would do a 
Framework build. That's a whole nightmare on it's own.
On Monday, 21 March 2011 at 15:25, Mike McQuaid wrote: 
> On 21 March 2011 00:03, Adam Vandenberg <flangy@gmail.com> wrote:
> > ("pip install numpy" works against a non-Framework version.)
> > 
> > For doing Py2App stuff, it is probably a much better idea to use an
> > official Python OS X installer for the Framework build, rather than
> > custom-compile.
> > Is there a reason to want to custom-compile Python when writing apps
> > for distribution, rather than using the provided downloader for 2.7.1?
> 
> I don't know huge amounts about Python in Homebrew but my opinion is
> the defaults should match upstream/OSX-native as closely as possible.
> 
> -- 
> Mike McQuaid
> http://mikemcquaid.com
> 

It's not a nightmare. You just have to pass `--framework` to the formula. 
It works great.

My proposal is to make `--framework` enabled my default, and have a 
`--unix` flag you pass in to do a unix style build instead.

-- 
Kenneth Reitz
http://kennethreitz.com/contact-me
On Monday, March 21, 2011 at 11:30 AM, Lee Packham wrote: 
> If we were to do that (match upstream/OSX-native) then we would do a 
Framework build. That's a whole nightmare on it's own.
> On Monday, 21 March 2011 at 15:25, Mike McQuaid wrote: 
> > On 21 March 2011 00:03, Adam Vandenberg <flangy@gmail.com> wrote:
> > > ("pip install numpy" works against a non-Framework version.)
> > > 
> > > For doing Py2App stuff, it is probably a much better idea to use an
> > > official Python OS X installer for the Framework build, rather than
> > > custom-compile.
> > > Is there a reason to want to custom-compile Python when writing apps
> > > for distribution, rather than using the provided downloader for 2.7.1?
> > 
> > I don't know huge amounts about Python in Homebrew but my opinion is
> > the defaults should match upstream/OSX-native as closely as possible.
> > 
> > -- 
> > Mike McQuaid
> > http://mikemcquaid.com
> 

You misunderstand me - I mean if someone has Python installed in Homebrew 
already and has installed packages etc. and then we force a framework 
build on them. The effect on their packages and the like is what I am 
referring to. I know the build process is simple.
On Monday, 21 March 2011 at 15:35, Kenneth Reitz wrote: 
> It's not a nightmare. You just have to pass `--framework` to the 
formula. It works great.
> 
> My proposal is to make `--framework` enabled my default, and have a 
`--unix` flag you pass in to do a unix style build instead.
> 
> -- 
> Kenneth Reitz
> http://kennethreitz.com/contact-me
> On Monday, March 21, 2011 at 11:30 AM, Lee Packham wrote:
> > If we were to do that (match upstream/OSX-native) then we would do a 
Framework build. That's a whole nightmare on it's own.
> > On Monday, 21 March 2011 at 15:25, Mike McQuaid wrote: 
> > > On 21 March 2011 00:03, Adam Vandenberg <flangy@gmail.com> wrote:
> > > > ("pip install numpy" works against a non-Framework version.)
> > > > 
> > > > For doing Py2App stuff, it is probably a much better idea to use an
> > > > official Python OS X installer for the Framework build, rather than
> > > > custom-compile.
> > > > Is there a reason to want to custom-compile Python when writing apps
> > > > for distribution, rather than using the provided downloader for 2.7.1?
> > > 
> > > I don't know huge amounts about Python in Homebrew but my opinion is
> > > the defaults should match upstream/OSX-native as closely as possible.
> > > 
> > > -- 
> > > Mike McQuaid
> > > http://mikemcquaid.com
>