PostgreSQL 9.6 snap and feedback

[Sergio Schvezov]

El 02/09/16 a las 13:59, Michael Hall escribió:
> On 09/02/2016 12:29 PM, Sergio Schvezov wrote:
>> El 02/09/16 a las 08:29, Mark Shuttleworth escribió:
>>>>> Usability is currently poor. PostgreSQL is cli heavy, so having all
>>>>> the well known commands with munged names like
>>>>> 'postgresql-9-6.pg-dump' instead of 'pg_dump' would stop adoption all
>>>>> by itself. I understand that this is being addressed, and I will be
>>>>> able to present the dozen or so commands with their preferred names.
>>>>> But this will also cause different issues, when I snap postgresql-10.
>>>>> postgresql-10 will have the same set of tools. So I'll have two sets
>>>>> on my path, each only able to deal with their own confinement. I think
>>>>> the search path needs a defined ordering (eg. alphabetically), and
>>>>> tools need to be available in both their prefixed and unprefixed form.
>>>>> I will need to have both postgresql-9-6 and postgresql-10 snaps
>>>>> installed in the same container, as this is the only migration path I
>>>>> can come up with (allowing postgresql-10.pg_upgrade access to the
>>>>> postgresql-9-6 containment via the content interface).
>>> 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.
>>>
>>>
>> 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.
>>
>> Here's a friday parlor trick
>>
>>      source $(pg.env)
>>
>> 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 :-)
>>
>>
> That would only work if the overlapping command name are from the same
> upstream project (postgresql in this example) but what if they are from
> different upstreams? For instance, some other database (let's say
> mariadb for sake of example) might also have a createdb command. Then
> you might page postgresql-9-6.createdb, postgresql-10.createdb and
> mariadb.createdb.

I don't understand how this relates to my response. Can you clarify? I 
am not even covering a case of the same upstream project but the same 
snap which could be made up of many upstream projects.