<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>