Hi,
I work at Canonical as part of the engineering team around Ubuntu and
Snapcraft [1].
We’re working on snaps, a platform to enable ISVs to directly control
delivery of software updates to their users, and make their software
available to a considerably wider audience via our snappy store.
Would someone on your team be willing to have a conversation with me
to discuss some ideas on how we can help deliver the latest php to
more users?
Best regards.
Alan Pope
Snap Advocate
Canonical - Ubuntu Engineering and Services
+44 (0) 7973 620 164
alan.pope@canonical.com
http://ubuntu.com/
We’re working on snaps, a platform to enable ISVs to directly control
delivery of software updates to their users, and make their software
available to a considerably wider audience via our snappy store.
Hi Alan,
Sorry to sound negative, but my immediate reaction to this is "Oh good, yet another package management and sandboxing technology!"
This probably isn't the place to discuss the USPs of this over all the systems that are already out there, but it does come across as a bit of an advert.
Are there particular challenges you're facing when packaging PHP specifically, or are you just hoping to recruit more volunteers to help you bootstrap your "store"?
Regards,
--
Rowan Collins
[IMSoP]
Hi Rowan,
Thanks for the prompt reply. Apologies if my mail comes over as an advert.
Sorry to sound negative, but my immediate reaction to this is "Oh good, yet another package management and sandboxing technology!"
:)
This one has existed for a while. Snaps evolved from our click
packaging on the phone which dates back a few years, but I get your
point.
Are there particular challenges you're facing when packaging PHP specifically, or are you just hoping to recruit more volunteers to help you bootstrap your "store"?
Actually we're not seeing challenges packaging PHP at all. Some
developers have already packaged PHP as a 'part' [1] in their own
application. A notable example would be NextCloud, in which the snap
contains Apache, MySql, PHP and NextCloud itself. So packaging it
isn't the issue. It's also less about bootstrapping and more about
getting the word out and finding where the gaps are. We found that
developers didn't know snap existed as a technology, hence my mail.
For PHP specifically I think one killer feature of snaps is that you
can have a bleeding edge build of PHP landing in the 'edge' channel in
the store automatically, directly from your master branch on github.
Adventurous users, testers and developers can then "snap install php
--edge" and know they're getting the latest build, untainted, directly
from you, the way you want to ship it. Stable builds can be pushed to
the 'stable' channel in the store, and more conservative users can
install that. We also support multiple 'tracks', so users can "snap
install" the version they want want easily, and track that series for
its lifetime, not having to worry that the distro they're using either
isn't up to date or has gone ahead of what they need.
What we're really after though is feedback. We've got documentation
[3], tutorials [4] and a fourm [5] where the developers hang out.
We're keen to know where the rough edges are, and what we can do to
improve the experience for developers and users alike.
[1] https://github.com/nextcloud/nextcloud-snap/blob/master/snap/snapcraft.yaml#L149
[2] https://snapcraft.io/docs/reference/channels
[3] https://snapcraft.io/docs/
[4] https://tutorials.ubuntu.com/
[5] https://forum.snapcraft.io/
Best regards,
Alan Pope
Snap Advocate
Canonical - Ubuntu Engineering and Services
+44 (0) 7973 620 164
alan.pope@canonical.com
http://ubuntu.com/
What we're really after though is feedback. We've got documentation
[3], tutorials [4] and a fourm [5] where the developers hang out.
We're keen to know where the rough edges are, and what we can do to
improve the experience for developers and users alike.
Your initial mail wanted me to check it out on snapcraft.io (never heard
of snaps before) and I had to go to
https://snapcraft.io/docs/snaps/intro to "get" what this is about.
For me these 3 point bullet list was the important part and thought it
would be better suited on the start page.
My Feedback 2€ ;)
- Markus
Hey,
A notable example would be NextCloud, in which the snap
contains Apache, MySql, PHP and NextCloud itself.
To my understanding this is the right place for this - snap is for an
"application" but aside from some developers PHP isn't the application
people are looking for. They are maybe looking for "a webserver with
PHP enabled" or NextCloud/Wordpress/moodle/whatever. It's a bit like
snapping up stdlibc ;-)
If somebody wants to add a snapfile or whatever might be needed we
could certainly add it Maybe it would see more maintenance than our
rpm spec file, which apparently hasn't seen a real change since 1999 :-
)
johhannes
Also note that we don't do binary release outside of Windows. We leave it
up to the various distributions. If this Snap thing, which I have also
never heard of, has the equivalent of an rpm .spec file that you wish to
contribute and keep up to date we can add that, but anything beyond that is
out of scope for us (including helping you get the word out about Snap).
You are welcome to pull the latest branches and automatically build snaps
of whatever versions of PHP you like, of course. It doesn't sound like you
need our help for that.
-Rasmus
On Wed, May 10, 2017 at 8:42 AM, Johannes Schlüter johannes@schlueters.de
wrote:
Hey,
A notable example would be NextCloud, in which the snap
contains Apache, MySql, PHP and NextCloud itself.To my understanding this is the right place for this - snap is for an
"application" but aside from some developers PHP isn't the application
people are looking for. They are maybe looking for "a webserver with
PHP enabled" or NextCloud/Wordpress/moodle/whatever. It's a bit like
snapping up stdlibc ;-)If somebody wants to add a snapfile or whatever might be needed we
could certainly add it Maybe it would see more maintenance than our
rpm spec file, which apparently hasn't seen a real change since 1999 :-
)johhannes
Hi again,
I appreciate the comments from everyone on the subject of snapping
php. I'm keen to pass your honest feedback to our team, so we can
understand why some software developers aren't keen on investing time
to make a snap.
What's the rationale behind not doing binary releases beyond Windows?
Is that a historical legacy because distro people did that for you, so
why bother, or some other reason? Also, I'm interested to know why
it's not seen as useful to have an automated build on each commit, and
an easy single-command way to get stable builds to stable channels?
All the best,
Al
Also note that we don't do binary release outside of Windows. We leave it up
to the various distributions. If this Snap thing, which I have also never
heard of, has the equivalent of an rpm .spec file that you wish to
contribute and keep up to date we can add that, but anything beyond that is
out of scope for us (including helping you get the word out about Snap). You
are welcome to pull the latest branches and automatically build snaps of
whatever versions of PHP you like, of course. It doesn't sound like you need
our help for that.-Rasmus
On Wed, May 10, 2017 at 8:42 AM, Johannes Schlüter johannes@schlueters.de
wrote:Hey,
A notable example would be NextCloud, in which the snap
contains Apache, MySql, PHP and NextCloud itself.To my understanding this is the right place for this - snap is for an
"application" but aside from some developers PHP isn't the application
people are looking for. They are maybe looking for "a webserver with
PHP enabled" or NextCloud/Wordpress/moodle/whatever. It's a bit like
snapping up stdlibc ;-)If somebody wants to add a snapfile or whatever might be needed we
could certainly add it Maybe it would see more maintenance than our
rpm spec file, which apparently hasn't seen a real change since 1999 :-
)johhannes
--
--
Alan Pope
Snap Advocate
Canonical - Ubuntu Engineering and Services
+44 (0) 7973 620 164
alan.pope@canonical.com
http://ubuntu.com/
I appreciate the comments from everyone on the subject of snapping
php. I'm keen to pass your honest feedback to our team, so we can
understand why some software developers aren't keen on investing time
to make a snap.
Since maintenance is already a little slow across many of the linux
distributions, adding more third party options is not a core project
matter? Windows is a little bit of a problem case since the vast
majority of users would not know where to start compiling from source,
so providing a clean binary source makes sense while people are prepared
to maintain it.
There is no problem with a third party creating a 'snap' and supporting
that, just as several sites provide pre-packaged windows and even linux
installs of the web stack. If that process becomes well supported, then
it can be reviewed, much like composer seems to have taken over as the
package manager of choice. It's still not the core way of managing
things. It's a matter of choice.
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
What's the rationale behind not doing binary releases beyond Windows?
Is that a historical legacy because distro people did that for you, so
why bother, or some other reason?
Essentially this. Beyond the "why bother" question, however, is the
simple matter that distro people are simply better positioned to do
this. I'm not going to enumerate the many reasons why this is. They
should be obvious.
Also, I'm interested to know why
it's not seen as useful to have an automated build on each commit, and
an easy single-command way to get stable builds to stable channels?
It is useful to have a build on every commit. There are (at least)
two automated CI systems doing that already.
-Sara
so we can understand why some software developers aren't keen on
investing time to make a snap.
You work for a commercial organisation - which is fine btw!.
If a commercial entity invests time + money in doing some activity,
they'd expect to see some commercial benefit.
If a purely open source project invests time in producing more binary
distributions, the only result they would see would be an increased
workload due to whoever is producing binaries is the first line of
support for issues with those binaries.
The current system, where PHP and the extensions are packaged by
Ubuntu, Debian, Centos etc people, who are then the first line of call
for bugs on that platform, prevents a large number of platform
specific bugs from reaching the PHP team.
make their software
available to a considerably wider audience via our snappy store
Two things:
i) I don't think the PHP project would actually get a considerably
wider audience by starting to release snaps. PHP is kind of available
in quite a few places already.
ii) The PHP project is already constrained by a lack of development
resources. Having someone manage these snaps and also triage the
increased number of platform specific issues is unlikely to be
something we could cope with.
cheers
Dan