Ticket #1300 (new enhancement)

Opened 8 years ago

Last modified 8 years ago

Ship pymoira and mrtools with Debathena

Reported by: vasilvv Owned by:
Priority: insignificant Milestone: The Distant Future
Component: -- Keywords:
Cc: Fixed in version:
Upstream bug:


pymoira is a Python library which provides access to Moira. Unlike the existing python-moira bindings, it does not depend upon any other C library (it even ~works under Windows!), it is thread-safe and it provides higher-level abstractions.

mrtools are set of command-line utilities built on the top of this library. They provide some nice features standard utilities do not have, like retrieving the list of lists a user is in or show how the user is included through a particular nested structure of the list.

The good thing is that I have already done the Debian packaging for both. The bad thing is that I am probably the only person who interacted with that code, so although I did some testing, the code probably needs more review.

pymoira: < https://github.com/vasilvv/pymoira>
mrtools: < https://github.com/vasilvv/mrtools>

Change History

comment:1 Changed 8 years ago by jdreed

I'm not immediately opposed, but I'm also curious why these need to be in the release rather than a locker, particularly if they're architecture-independent.

comment:2 Changed 8 years ago by vasilvv

Well, I am not sure whether "Python modules in Athena lockers" is a thing and if it is, how well does it work?

I also do not know if bash completion scripts are fetched from the locker.

In general, the two reasons I don't want this software to be in the locker are:

  1. I want to be able to run it on a trusted machine and I don't have any secure locker to put it in. I don't trust my null instance with hosting it in my locker, and the other lockers in which software is commonly put have even more null instances with write access on ACL (which is something that makes me feel particularly sad, especially given that I know for sure some people with null instances in gsipbbin log into random cluster machines).
  1. Debian packaging is in general a better way of distributing software than lockers. In particular, I can track the dependencies without having to "lockerize the library world" (Python software has library dependencies too) and it's more difficult to screw up when updating software.

comment:3 Changed 8 years ago by jdreed

So, one concern I have is the potential for bitrot, given that the API is copied here. If there were a clever way to pick up constants from the Moira source while still retaining the pure-Python implementation, that might be better. (For example, since you last wrote this, a new user Status (10) was added.).

You are correct that bash completion scripts aren't (by default) fetched from lockers. There's probably a clever way to do this, but I haven't looked. Python modules in lockers, however, is very much a thing. I'm not sure what you mean by "secure locker". Certainly getting a locker dedicated to this should be trivial in the sipb cell, and slightly less trivial but easily possible in the Athena cell. You can certainly put it in your locker -- simply take your null instance off the ACL for the relevant directories, and add your root or extra instance. (I suppose your null instance, as it owns the locker, can technically force itself back onto the ACL, but that seems ... unlikely.)

I think this would be an ideal bootstrap project for the nonexistent SIPB apt repo ( ticket:19, originally #442), if you felt like taking that on. But a locker (a standalone one, if you're concerned about security) would also be ideal, as we would love to better extend Debathena utilities (e.g. 'add') to to better support e.g. PYTHONPATH (#228), and this might be a good test case for that.

Note: See TracTickets for help on using tickets.