[illumos-Developer] webrev: 278 get rid zfs of python and pyzfs dependencies

[Garrett D'Amore]

On Thu, 2010-11-11 at 14:06 -0800, Erik Trimble wrote:
> On 11/11/2010 1:37 PM, Bryan Cantrill wrote:
> > On Thu, Nov 11, 2010 at 12:17 PM, Garrett D'Amore<garrett at nexenta.com>  wrote:
> >> http://cr.illumos.org/view/jpj55p64/
> >>
> >> This work was done by another Nexentian.  The goal is to eliminate the
> >> use of Python from zfs, which was "split" into having some percentage of
> >> its code written in Python and the rest in C.  (Fixing this is a step
> >> along the road towards making python installation "optional" at Runtime.
> >> The other dependencies are beadm and IPS.  We're working on both of
> >> those as well, and not all distros will use IPS anyway.)
> >>
> >> Please provide feedback.  The timer on this expires in one week.
> > +UINT64_MAX.
> >
> >          - Bryan
> >
> > _______________________________________________
> > Developer mailing list
> > Developer at lists.illumos.org
> > http://lists.illumos.org/m/listinfo/developer
> 
> Personally, as an admin, I prefer to see a related suite of tools all 
> use the same language support, rather than have it scattered across 
> several. For two major reasons:  (1) if I have to look at the code, it's 
> simpler to re-learn 1 language than 2  (let's face it, as an admin, it 
> takes a day or two for me to get back in the groove for reading esoteric 
> code in a language I haven't used in a year or more)  and (2) it makes 
> dependencies simpler -   that is, if I need ABC suite of utils, I would 
> like to know that I really don't need 15 different other tools to 
> support it.  Now, I know modern packaging systems help with this, but 
> it's still annoying to have to update lots and lots of stuff every time 
> some one thing changes.
> 
> So, in this case, I think it's a Good Thing that we move the ZFS tools 
> to all C implementation, and dump python.
> 
> I'm less enthusiastic about removing python from beadm, where (to me) 
> using Python as the language for all that beadm does seems, well, a 
> better idea than C.  But, that's entirely up to whomever wants to tackle 
> the project.

Ah, but see, you don't know about tbeadm.  Which is basically beadm
itself, but written in C, and maintained in the libbe tree instead of as
a deliverable.  Essentially, we already have two versions of beadm.
tbeadm needs only a tiny bit of love (adding gettext() and some message
and command line syntax tweaks mostly) before it can replace the python
beadm.  And then we can have just *one* implementation of this, instead
of two. :-)

	- Garrett
> 
> I'm just for picking 1 language, and using that one.
>