AloisMahdal
commented
7 years ago One name I was thinking about is upm. This is based on the idea that if what preupgrade-assistant employs here is called "upgrade path", then the element forming that could be called "upgrade path module", ie. UPM.
That would mean:
#!/usr/bin/python
import preupg.upm
preupg.upm.debug("hello")
preupg.upm.exit('informational')and
#!/bin/bash
. /usr/share/preupg/preupg_upm.sh
preupg_upm_debug hello
preupg_upm_exit informationalor (depending on output of discussions in #186):
#!/bin/bash
. /usr/share/preupg/preupg_upm.sh
upm_debug hello
upm_exit informational
Currently, we have two ports of upgrade module API:
preupg.script_api - a Python port,
common.sh - a Bash port.
Neither of names used here is good.
Whatever context these names might be encountered in (read: existing modules, man pages, our docs, our trackers), terms "API", "script" and "common" are all already implied. In fact, they are implied by almost any (Python) programming context: any Python or Bash programs can be called "scripts", Python module or a sourced Bash file already is an API and any API is "common" by definition.
We need to come up with better, usable and final name.
Following is what should be considered for the debate:
In future, we might want to expose outer preupgrade-assistant API (eg. to allow people write Ansible modules). That is, we might want to reserve
preupgfor that.Name should be brief but specific.
Name should be informative, i.e. not include obvious words as mentioned above.