Re: [IBMiOSS] Early impressions of Litmis Spaces for Python

For me, the holy grail is being able to issue pip install commands and

have them work even when the package being installed has parts that are
implemented in C and thus must be compiled for the target platform.

. . .

Kevin Adler has spoken a few times about this and related topics.

We're incrementally working towards that. For example, Kevin recently
informed me that the libstdc++-devel rpm was necessary to gain access to
some C include files I was missing for Node.js compiles. I then added that
rpm to the pkg_perzl_gcc-4.8.3.lst file(n1).

n1 - http://bit.ly/ibmichroot-pkg-perzl-gcc-4-8-3-lst

In short, it's a work in progress that is getting better every day on many
fronts (the IBMers are putting out ~a lot~ of IBM i OSS the past two
years). Early adopters are getting skinned knees. All of your posts to
the forums conveying issues are very important so the holes can be found
and fixed; either by IBM or the community.

Aaron Bartell
litmis.com - Services for open source on IBM i


On Thu, Aug 11, 2016 at 1:17 PM, John Yeung <gallium.arsenide@xxxxxxxxx>
wrote:

On Thu, Aug 11, 2016 at 1:12 PM, Aaron Bartell <aaronbartell@xxxxxxxxx>
wrote:

I'd love feedback on things that you feel I don't explain well. I

believe

"containers" play an important role in the future of running PASE

workloads

on IBM i, and right now chroot is the best one we have (that I am aware
of).

I get the broad concept of containers. I just meant that I don't know
specifically how chroot plays out on the i (surely there are some
quirks that come from that). I also don't know the ramifications even
on a mainstream Unix or Linux platform of what happens when you're
running in a chroot environment versus not. Ideally none, I am sure.
But we all know real life doesn't always match up with the ideal.

Btw, chroot (aka ibmichroot) is delivered with 5733OPS opt 3. IBM
named opt 3 "GCC" which is somewhat a misnomer.

IBM is famous for not being great at naming.

In short, 5733OPS opt 3
gives you ease of chroot creation via shell scripts, and ease of

installing

perzl.org rpms via shell scripts.

For me, the holy grail is being able to issue pip install commands and
have them work even when the package being installed has parts that
are implemented in C and thus must be compiled for the target
platform. And that compilation should be transparent to whoever is
issuing the pip command. When I first heard about Option 3, I was
hoping that it would serve that purpose, but I'm increasingly getting
the sense that it doesn't, at least not yet; and also the sense that
this is an extremely tough nut to crack.

Kevin Adler has spoken a few times about this and related topics. I
know he would like this to work, and more generally for anything in
PASE, not just Python.

John Y.
--
This is the IBMi Open Source Roundtable (OpenSource) mailing list
To post a message email: OpenSource@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/opensource
or email: OpenSource-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/opensource.