PostgreSQL 9.6 snap and feedback

[Sergio Schvezov]

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 :-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/snapcraft/attachments/20160902/da9dd463/attachment.html>