incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Wild <ian.w...@wandisco.com>
Subject Re: OSX installation (Was: Re: [ANNOUNCE] Apache Bloodhound 0.1.0 incubating Released)
Date Wed, 19 Sep 2012 09:39:38 GMT
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 <olemis@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 <chambej@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:
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message