You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@bloodhound.apache.org by Gary Martin <ga...@wandisco.com> on 2012/09/14 18:31:34 UTC

OSX installation (Was: Re: [ANNOUNCE] Apache Bloodhound 0.1.0 incubating Released)

On 09/14/2012 03:56 PM, John Chambers wrote:
> Great news.
>
> Congratulations to all involved. I have tried it on OSX 10.8.1 and it all
> works fine for me, once I had installed the command line tools.
>
> John
>

More great news. Thanks John.

It would be nice if we could find a way to get rid of the need for the 
command line tools install. I think it is probably a virtualenv issue 
and so, strictly speaking, is not a hard requirement. Should we 
encourage people trying Bloodhound out on OSX to skip this or recommend 
a different way of isolating their python environments?

Cheers,
     Gary

Re: OSX installation (Was: Re: [ANNOUNCE] Apache Bloodhound 0.1.0 incubating Released)

Posted by Branko Čibej <br...@wandisco.com>.
It is perfectly valid to require Xcode command-line tools for people
who're building from source. An installable binary package will not
depend on anything else, but that's off-topic for this project.

I'll take another example from Subversion which has a number of
requirements for people who build from SVN, a smaller set of
requirements for people who build from tarballs (e.g., the latter do not
need autoconf). So it's worth investigating if it's possible to build
the release tarball such that OSX users don't need Xcode; but I wouldn't
waste too much time doing that.

-- Brane


On 19.09.2012 16:32, Gary Martin wrote:
> Virtualenv is not a hard requirement but is convenient. I believe that
> we already have instructions that point out that activating a
> virtualenv is optional. I think we will just have to present this
> information to OSX users to allow them to make their own choice.
>
> If we can avoid wasting time in creating a full installer, this would
> be a very good thing. I believe that we are doing enough by providing
> appropriate instructions for successful installation and good basic
> initial configuration.
>
> Cheers,
>     Gary
>
>
> On 09/19/2012 03:03 PM, John Chambers wrote:
>> If using virtualenv is a hard requirement for the basic running of
>> Bloodhound then we just need to document, that on OSX we have a
>> dependancy
>> on the xcode command line tools. Unless we can find a way around
>> this. I am
>> neither an expert on OSX or python (yet).
>>
>> As for the wide issue of providing installer packages I agree with
>> Ian that
>> these are normally provided outside of the main project along with
>> providing support and other ancillary services. But we still need to
>> provide the instruction to get Bloodhound up and running as quickly and
>> easily as possible, with the least impact on the users existing system.
>>
>


-- 
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download


Re: OSX installation (Was: Re: [ANNOUNCE] Apache Bloodhound 0.1.0 incubating Released)

Posted by Gary Martin <ga...@wandisco.com>.
Virtualenv is not a hard requirement but is convenient. I believe that 
we already have instructions that point out that activating a virtualenv 
is optional. I think we will just have to present this information to 
OSX users to allow them to make their own choice.

If we can avoid wasting time in creating a full installer, this would be 
a very good thing. I believe that we are doing enough by providing 
appropriate instructions for successful installation and good basic 
initial configuration.

Cheers,
     Gary


On 09/19/2012 03:03 PM, John Chambers wrote:
> If using virtualenv is a hard requirement for the basic running of
> Bloodhound then we just need to document, that on OSX we have a dependancy
> on the xcode command line tools. Unless we can find a way around this. I am
> neither an expert on OSX or python (yet).
>
> As for the wide issue of providing installer packages I agree with Ian that
> these are normally provided outside of the main project along with
> providing support and other ancillary services. But we still need to
> provide the instruction to get Bloodhound up and running as quickly and
> easily as possible, with the least impact on the users existing system.
>


Re: OSX installation (Was: Re: [ANNOUNCE] Apache Bloodhound 0.1.0 incubating Released)

Posted by John Chambers <ch...@apache.org>.
If using virtualenv is a hard requirement for the basic running of
Bloodhound then we just need to document, that on OSX we have a dependancy
on the xcode command line tools. Unless we can find a way around this. I am
neither an expert on OSX or python (yet).

As for the wide issue of providing installer packages I agree with Ian that
these are normally provided outside of the main project along with
providing support and other ancillary services. But we still need to
provide the instruction to get Bloodhound up and running as quickly and
easily as possible, with the least impact on the users existing system.

Re: OSX installation (Was: Re: [ANNOUNCE] Apache Bloodhound 0.1.0 incubating Released)

Posted by Ian Wild <ia...@wandisco.com>.
This is a slightly wider point, but I think it might be helpful if we can
agree on the difference between the job of the Apache based development
community and that of the packagers, who we can expect to build
distributions of the project. The reference (at least in my mind) is Apache
Subversion whereby the source is delivered by the project and numerous
organisations then use that source to build and ship compiled binaries with
nice installers etc.

For me the priority with Bloodhound should be creating a functionality and
usability experience which matches / exceeds commercially available
solutions. Whilst the packaging is important to the success of Bloodhound,
I'm not sure that should be the focus of the Apache Bloodhound community's
development efforts. Does that make sense to everyone?

Ian


On Wed, Sep 19, 2012 at 1:09 AM, Olemis Lang <ol...@gmail.com> wrote:

> AFAIK one of the goals of pip is exactly to add multi-platform
> uninstall commands for python packages . Python packaging modules have
> been patched and improved since long time ago due to the fact that
> initial design of distutils module didn't consider many capabilities .
> Hence the need for setuptools, distribute, pip , ... For some reason
> uninstall commands is one of those «missing features» . However , to
> be honest I *never* install python packages via pip . I use GNU/Linux
> (Debian + Ubuntu to be more precise ...) most of the time since years
> ago and I always rely on the native deb+apt package manager to handle
> this . They provide a lot of tools I use quite often and have been
> actively developed since long time ago . So I'm way behind on the
> field of building multi-platform installers for Python packages.
>
> Just a comment ... now, to the point ... In the specific case of
> Bloodhound we could try to use bundles . Nonetheless , considering the
> fact that we rely on t-h.o plugins then licensing and other
> interactions shall be considered when preparing a release . Besides
> we'll still need virtualenvs because our copy of trac differs
> substantially from the mainstream . And substantially means that some
> important features in Bloodhound will not work if using Trac packages
> lacking features introduced in patches committed onto ASF repository .
>
> So ... picture is complicated . Maybe the solution is to build a
> native Mac OS installer for virtualenv ? Does such a solution already
> exist ? Would it be enough ? Maybe we decide to enhance installer to
> detect whether command line tools are not available and install them ?
>
> Depending on the answers maybe we'll get nowhere and walk in circles ,
> but at least I tried to think about it , and maybe someone starting
> from here will find the light at the end of the tunnel
>
>
> On 9/17/12, John Chambers <ch...@apache.org> wrote:
> >>
> >> It would be nice if we could find a way to get rid of the need for the
> >> command line tools install. I think it is probably a virtualenv issue
> and
> >> so, strictly speaking, is not a hard requirement. Should we encourage
> >> people trying Bloodhound out on OSX to skip this or recommend a
> different
> >> way of isolating their python environments?
> >
> >
> > I am no python expert but I would think we need to make the installation
> as
> > painless as possible which does mean we need to make it easy to uninstall
> > as well. We should also make the installation process OS agnostic if at
> all
> > possible. I will take a look around at how other python projects deal
> with
> > installation, unless you have already done this exercise. If you want me
> to
> > look at something in particular then let me know.
> >
> > Cheers
> >
> > John Chambers
> >
>
>
> --
> Regards,
>
> Olemis.
>
> Blog ES: http://simelo-es.blogspot.com/
> Blog EN: http://simelo-en.blogspot.com/
>
> Featured article:
>

Re: OSX installation (Was: Re: [ANNOUNCE] Apache Bloodhound 0.1.0 incubating Released)

Posted by Olemis Lang <ol...@gmail.com>.
AFAIK one of the goals of pip is exactly to add multi-platform
uninstall commands for python packages . Python packaging modules have
been patched and improved since long time ago due to the fact that
initial design of distutils module didn't consider many capabilities .
Hence the need for setuptools, distribute, pip , ... For some reason
uninstall commands is one of those «missing features» . However , to
be honest I *never* install python packages via pip . I use GNU/Linux
(Debian + Ubuntu to be more precise ...) most of the time since years
ago and I always rely on the native deb+apt package manager to handle
this . They provide a lot of tools I use quite often and have been
actively developed since long time ago . So I'm way behind on the
field of building multi-platform installers for Python packages.

Just a comment ... now, to the point ... In the specific case of
Bloodhound we could try to use bundles . Nonetheless , considering the
fact that we rely on t-h.o plugins then licensing and other
interactions shall be considered when preparing a release . Besides
we'll still need virtualenvs because our copy of trac differs
substantially from the mainstream . And substantially means that some
important features in Bloodhound will not work if using Trac packages
lacking features introduced in patches committed onto ASF repository .

So ... picture is complicated . Maybe the solution is to build a
native Mac OS installer for virtualenv ? Does such a solution already
exist ? Would it be enough ? Maybe we decide to enhance installer to
detect whether command line tools are not available and install them ?

Depending on the answers maybe we'll get nowhere and walk in circles ,
but at least I tried to think about it , and maybe someone starting
from here will find the light at the end of the tunnel


On 9/17/12, John Chambers <ch...@apache.org> wrote:
>>
>> It would be nice if we could find a way to get rid of the need for the
>> command line tools install. I think it is probably a virtualenv issue and
>> so, strictly speaking, is not a hard requirement. Should we encourage
>> people trying Bloodhound out on OSX to skip this or recommend a different
>> way of isolating their python environments?
>
>
> I am no python expert but I would think we need to make the installation as
> painless as possible which does mean we need to make it easy to uninstall
> as well. We should also make the installation process OS agnostic if at all
> possible. I will take a look around at how other python projects deal with
> installation, unless you have already done this exercise. If you want me to
> look at something in particular then let me know.
>
> Cheers
>
> John Chambers
>


-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:

Re: OSX installation (Was: Re: [ANNOUNCE] Apache Bloodhound 0.1.0 incubating Released)

Posted by John Chambers <ch...@apache.org>.
>
> It would be nice if we could find a way to get rid of the need for the
> command line tools install. I think it is probably a virtualenv issue and
> so, strictly speaking, is not a hard requirement. Should we encourage
> people trying Bloodhound out on OSX to skip this or recommend a different
> way of isolating their python environments?


I am no python expert but I would think we need to make the installation as
painless as possible which does mean we need to make it easy to uninstall
as well. We should also make the installation process OS agnostic if at all
possible. I will take a look around at how other python projects deal with
installation, unless you have already done this exercise. If you want me to
look at something in particular then let me know.

Cheers

John Chambers