Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » Snapping php »

Snapping php

php.internals

Alan Pope

9 years ago
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? http://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/

Rowan Collins

9 years ago
On 10 May 2017 09:55:28 BST, Alan Pope <alan.pope@canonical.com> wrote:
>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]

Alan Pope

9 years ago
Hi Rowan, Thanks for the prompt reply. Apologies if my mail comes over as an advert. On 10 May 2017 at 14:04, Rowan Collins <rowan.collins@gmail.com> wrote:
> 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/

Markus Fischer

9 years ago
On 10.05.17 16:05, Alan Pope wrote:
> 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

Johannes Schlueter

9 years ago
Hey, On Mi, 2017-05-10 at 15:05 +0100, Alan Pope wrote:
> 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

Rasmus Lerdorf

9 years ago
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:

Alan Pope

9 years ago
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 On 10 May 2017 at 18:25, Rasmus Lerdorf <rasmus@lerdorf.com> wrote:
> 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, >> >> On Mi, 2017-05-10 at 15:05 +0100, Alan Pope wrote: >> > 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 >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php >> >
-- Alan Pope Snap Advocate Canonical - Ubuntu Engineering and Services +44 (0) 7973 620 164 alan.pope@canonical.com http://ubuntu.com/

Lester Caine

9 years ago
On 24/05/17 12:36, Alan Pope wrote:
> 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

Sara Golemon

9 years ago
On Wed, May 24, 2017 at 7:36 AM, Alan Pope <alan.pope@canonical.com> wrote:
> 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

Dan Ackroyd

9 years ago
On 10 May 2017 at 15:05, Alan Pope <alan.pope@canonical.com> wrote:
> 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