<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
El 02/09/16 a las 08:29, Mark Shuttleworth escribió:<br>
<blockquote
cite="mid:2c9974b9-b116-57ba-ac79-cb3933d917b1@ubuntu.com"
type="cite">
<blockquote type="cite" style="color: #000000;">
<pre wrap=""><span class="moz-txt-citetags">> </span>Usability is currently poor. PostgreSQL is cli heavy, so having all
<span class="moz-txt-citetags">> </span>the well known commands with munged names like
<span class="moz-txt-citetags">> </span>'postgresql-9-6.pg-dump' instead of 'pg_dump' would stop adoption all
<span class="moz-txt-citetags">> </span>by itself. I understand that this is being addressed, and I will be
<span class="moz-txt-citetags">> </span>able to present the dozen or so commands with their preferred names.
<span class="moz-txt-citetags">> </span>But this will also cause different issues, when I snap postgresql-10.
<span class="moz-txt-citetags">> </span>postgresql-10 will have the same set of tools. So I'll have two sets
<span class="moz-txt-citetags">> </span>on my path, each only able to deal with their own confinement. I think
<span class="moz-txt-citetags">> </span>the search path needs a defined ordering (eg. alphabetically), and
<span class="moz-txt-citetags">> </span>tools need to be available in both their prefixed and unprefixed form.
<span class="moz-txt-citetags">> </span>I will need to have both postgresql-9-6 and postgresql-10 snaps
<span class="moz-txt-citetags">> </span>installed in the same container, as this is the only migration path I
<span class="moz-txt-citetags">> </span>can come up with (allowing postgresql-10.pg_upgrade access to the
<span class="moz-txt-citetags">> </span>postgresql-9-6 containment via the content interface).
</pre>
</blockquote>
<pre wrap="">Yes, these are very useful practical items of feedback for the command
work. Let's promise to take that up in a sprint, when it's close to the
top of our priority list. As a straw man it seems that we want groups of
snaps (your pg versions) to be able to overlap in command names, but
have only one of them get that top-level space at a time. That's a
little bit like update-alternatives but with a snap as the level of
granularity. If pg-10 is your default then all the top-level commands
are pg-10, others are pg-X.command.
</pre>
</blockquote>
<br>
A solution for this that could work today is to have some sort of
env setup (like done with python virtual envs), source the correct
env and with aliases or PATH setups make sure the right top level
names are seen.<br>
<br>
Here's a friday parlor trick<br>
<br>
source $(pg.env)<br>
<br>
And `pg.env` would just echo the path to the file withing the snap
to source. Not totally user friendly and probably could be made more
straightforward but it does get the job done. Maybe one day we can
get a `snap env <snap>` command (thinking out loud/writing),
who knows :-)<br>
</body>
</html>