installing Doorstop on macOS (for RTEMS use)

[Joel Sherrill]

On Thu, Oct 10, 2019 at 4:26 PM Chris Johns <chrisj at rtems.org> wrote:

> On 11/10/19 1:15 am, Andrew Butterfield wrote:
> > Dear RTEMS Users,
> >
> >  Sebastian Huber asked me to check the availability of Doorstop (
> https://pypi.org/project/doorstop/) for macOS, and to report my
> experience on this mailing list.
> >
> >  It is planned to use this for RTEMS requirements in the RTEMS
> qualification project.
> >
> > It turned out to install really easily on my machine, in few 10s of
> seconds
> >
>
> <sigh>
>
> > The following is a record of my system setup w.r.t. python,
> > and the installation process.
> >
> >
> > Hardware/OS: MacBook Pro, 2.8Ghz i7, 16GB ram, 500GB flash, macOS 10.14.6
> >
> > python state:
> >
> > ~> which python
> > /usr/local/bin/python
>   ^^^^^^^^^^^^^^
> Hmmm ...
> > ~> python --version
> > Python 2.7.16
> >
> > ~> which python3
> > /usr/local/bin/python3
> > ~> python3 --version
> > Python 3.7.4
> >
> > ~> which pip
> > /usr/local/bin/pip
> > ~> pip --version
> > pip 19.0.3 from /usr/local/lib/python2.7/site-packages/pip (python 2.7)
> >
> > ~> which pip3
> > /usr/local/bin/pip3
> > ~> pip3 --version
> > pip 19.1.1 from /usr/local/lib/python3.7/site-packages/pip (python 3.7)
> >
> > Both pythons are 'brew' versions. Chris Johns said we should only use
> > the native installed versions.
>
> I am actually saying this is currently all we need to build our tool set. I
> cannot afford to have homebrew or macport packages installed because what I
> might have installed at any point in time may effect the building of the
> tools
> and I would never know and if I step on a bug where is the problem.
>
> I do not have the time or resources to maintain our tool sets when
> building with
> homebrew and macports packages installed. If an issue is found is the
> problem in
> the tools or an installed package. I would need to determine which part
> and look
> for a solution. I do not want to become a Mac package maintainer or a MacOS
> expert in a wide number of open source packages.
>
> I have found the Xcode command line tools from Apple to be stable over a
> number
> of years and I have found Apple and GCC to be responsive to any issues I
> raise.
> I have raised a number of bugs with both parties and in each case I seem
> to be
> one of first to uncover them.
>
> > However other tools I may choose to used
> > often need to be installed using 'brew' and you would be amazed how many
> > of those have python as a (brew) dependency.
>
> This is one alternative and one that brings other often more complicated
> issues.
>
> How do we managing building all the tools for all architectures making
> sure they
> build and work with any mix of installed packages at whatever versions they
> have? Our mailing list has a number of posts about the RSB not building
> tools on
> MacOS and my first question is always "are any packages installed from
> homebrew
> or macports?" and it normally ends up being related.
>
> I have no idea how you would control and specify a set of suitable
> packages for
> homebrew or macports. I do know if you use a specific version of Xcode on a
> specific version of MacOS you will end up with the same tool set I have
> built
> and tested. I think this is important and important for our users.
>

I'm a CentOS user and there is a parallel type of situation. I avoid using
odd repositories
and have resisted using the official "software collections" which include a
newer Python.
CentOS 7 ships by default with Python 2.7.5 and I will stay with that.

Disclaimer: For Sphinx support, I use the Python 3 software collection.
Sphinx's need for
a newer Python is what drove me off CentOS 6.

Sticking with base installs and official sources of packages keeps us as
maintainers
inline with what "real" users have. Large organization uses in the US are
CentOS/RHEL
users with strict security controls. Those are our corporate and scientific
users. I try hard
to suffer as much as they do. They can't just switch to Mint, FreeBSD, or
install something
from an odd repo.

RTEMS isn't a hobby (or toy) project and most of its users are stuck in
serious industrial
settings. As core developers, we have to respect that and suffer along.

--joel


>
> Chris
> _______________________________________________
> users mailing list
> users at rtems.org
> http://lists.rtems.org/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20191010/0572606b/attachment-0001.html>