PostgreSQL 9.6 snap and feedback

[Michael Hall]

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.


Michael Hall
mhall119 at ubuntu.com