Page MenuHomePhabricator

Decide whether and how to consolidate Wmfdata-Python and Refinery's Python modules
Open, LowPublic

Description

Refinery contains several Python modules that duplicate or complement functionality in Wmfdata-Python. For example, refinery.util.get_dbnames_from_mw_config and wmfdata.utils.get_dblist do the same thing, as do refinery.hive.query and wmfdata.hive.run. Obviously, it's preferable to avoid this code duplication.

Additionally some folks in Data Engineering have suggested that other Python functionality that exists only in Refinery should be moved into Wmfdata-Python: T293700#7438485, T292479#7482513.

Important points to consider:

  • Should there be a general consolidation or just a partial one?
  • Would adding modules aimed at data engineers to Wmfdata-Python make it harder for analysts to learn to use the package?
  • How would updates be distributed? Both Refinery and Wmfdata-Python have different homegrown update methods.
  • How would ownership of a combined package be handled?

Event Timeline

I think we'd like to make the python stuff that refinery does now be able to use conda environments. If we can do that, it would probably be better to do it the other way around: make refinery depend on wmfdata-python. refinery has a ton more than just python code, and those little python libs in there should be factored out.

ldelench_wmf moved this task from Triage to Backlog on the Product-Analytics board.
nshahquinn-wmf renamed this task from Upstream relevant parts of wmfdata-python into refinery to Decide whether and how to consolidate Wmfdata-Python and Refinery's Python modules.Dec 22 2021, 2:59 AM
nshahquinn-wmf edited projects, added: Data-Engineering; removed: Analytics-Radar.
nshahquinn-wmf updated the task description. (Show Details)

More related stuff: In T296543: Tooling for Deploying Conda Environments are working on some shared python libs related to airflow, and along the way I've copied and modified some conda related code from wmfdata.