Search results do not distinguish between a snappy package that provides an app framework and one that does not

[Timothy R. Chavez]

Assuming Ubuntu Core images will let you install any snappy package and not just snappy packages of app frameworks, I believe that showing whether a package provides an app framework or not in search / query results for a package will be necessary as installing an app container will change the system in specific ways. For example, new applications will become installable (in the example below that would be 'owncloud').

ubuntu@localhost:~$ snappy versions
Part Tag Installed Available Fingerprint Active
ubuntu-core edge 141 - 7f068cb4fa876c *
ubuntu@localhost:~$ snappy search ""
Part Version Description
camlistore 0.8 Camlistore
go-example-webserver 1.0.1 Minimal Golang webserver for snappy
hello-world 1.0.3 Hello world example
xkcd-webserver 0.3.1 Show random XKCD compic via a build-in webserver
docker 1.3.2.007 The docker app deployment mechanism

ubuntu@localhost:~$ snappy install docker
docker 4 MB [========================================================================================================================================] OK
Part Tag Installed Available Fingerprint Active
docker edge 1.3.2.007 - b1f2f85e77adab *
ubuntu@localhost:~$ snappy search ""
Part Version Description
camlistore 0.8 Camlistore
go-example-webserver 1.0.1 Minimal Golang webserver for snappy
hello-world 1.0.3 Hello world example
xkcd-webserver 0.3.1 Show random XKCD compic via a build-in webserver
owncloud 7.0.3.008 Owncloud 7.0.3 for snappy
docker 1.3.2.007 The docker app deployment mechanism

[James Tait (jamestait)]

The store does actually have the capability to indicate the content of a package, via a field appropriately called "content". However, this field currently only allows "scope" and "application" as values, with the latter being the default. It would make sense to allow additional values here, and probably to have the content types configurable via the devportal admin.

[James Westby (james-w)]

James Tait <email address hidden> writes:

> The store does actually have the capability to indicate the content of a
> package, via a field appropriately called "content". However, this field
> currently only allows "scope" and "application" as values, with the
> latter being the default. It would make sense to allow additional values
> here, and probably to have the content types configurable via the
> devportal admin.

In this case wouldn't it be better provided by something like

  provided_frameworks: [...]

?

Maybe the type could change as well, but it will be important to know
the frameworks that are provided, and the client could translate this in
the display however they want.

Thanks,

James

[Alexander Sack (asac)]

yes i agree that making it easy to distinguish between frameworks and snapps in search, versions etc. would be worthwhile. Will feed this in our console experience pipeline...

[Leo Arias (elopio)]

We no longer have frameworks. Marking as invalid.
I'm going to ask zyga how the interfaces, plugs and slots of each snap will be displayed.