Hi Everyone, I've updated the Pharo 6 snap package for Ubuntu. The major advantages of using the snap package are: - No need to install all the 32 bit dependencies on a 64 bit system, they're all contained and isolated within the snap package. - Automagically distinguish between 32 bit and 64 bit images and run the appropriate VM (as with the ZeroConf package, the 64 bit VM still needs more testing). To get Pharo up and running on Ubuntu 16.04 or later: # Install Pharo $ sudo snap install --candidate pharo --classic # If your system isn't configured for threaded heartbeat: $ sudo pharo.config # Download the latest Pharo 6 image $ pharo.getimage # Go... $ pharo.ui Pharo.image # or: $ pharo Pharo.image eval 4+3 To get a list of available commands: $ snap info pharo If you're on Debian or Ubuntu 14.04 you'll need to install snapd, see https://snapcraft.io/docs/core/install The VM is the threaded heartbeat, dated 201705310241. The installation flags are: --candidate - The edge and beta channels are for development versions. It progresses to candidate and then stable. --classic - Snap packages are normally sandboxed for security reasons. Since Pharo is a development environment in which we want to be able to run any executable, or load any library, it is installed with access to the entire system (as the running user). Why use snap packages? - They include all dependencies. In particular, for the 32 bit versions, this means that it isn't necessary to install all the 32 bit architecture and associated dependencies. - Including dependencies means that there shouldn't be any problems with incompatible library versions when upgrading. Why not use snap packages? - It's a relatively new technology, with a number of rough edges. - There may still be issues with its sandboxing that I haven't discovered yet. - Because the package uses classic confinement, it isn't cross-distribution in practice (unfortunately). Please let me know of any other advantages or disadvantages you think should be listed here. If you don't trust me to configure your system correctly (which requires sudo): - All the scripts that make up the sub-commands are visible, e.g. pharo.config can be viewed at /snap/pharo/current/usr/bin/CONFIG The packaging code is at: https://github.com/akgrant43/pharo-snap Cheers, Alistair
THANKS A LOT ALISTAIR. I mean it :) On Tue, Jun 13, 2017 at 10:58 AM, Alistair Grant <akgrant0710@gmail.com> wrote:
Hi Everyone,
I've updated the Pharo 6 snap package for Ubuntu.
The major advantages of using the snap package are:
- No need to install all the 32 bit dependencies on a 64 bit system, they're all contained and isolated within the snap package. - Automagically distinguish between 32 bit and 64 bit images and run the appropriate VM (as with the ZeroConf package, the 64 bit VM still needs more testing).
To get Pharo up and running on Ubuntu 16.04 or later:
# Install Pharo $ sudo snap install --candidate pharo --classic # If your system isn't configured for threaded heartbeat: $ sudo pharo.config # Download the latest Pharo 6 image $ pharo.getimage # Go... $ pharo.ui Pharo.image # or: $ pharo Pharo.image eval 4+3
To get a list of available commands:
$ snap info pharo
If you're on Debian or Ubuntu 14.04 you'll need to install snapd, see https://snapcraft.io/docs/core/install
The VM is the threaded heartbeat, dated 201705310241.
The installation flags are:
--candidate - The edge and beta channels are for development versions. It progresses to candidate and then stable. --classic - Snap packages are normally sandboxed for security reasons. Since Pharo is a development environment in which we want to be able to run any executable, or load any library, it is installed with access to the entire system (as the running user).
Why use snap packages?
- They include all dependencies. In particular, for the 32 bit versions, this means that it isn't necessary to install all the 32 bit architecture and associated dependencies. - Including dependencies means that there shouldn't be any problems with incompatible library versions when upgrading.
Why not use snap packages?
- It's a relatively new technology, with a number of rough edges. - There may still be issues with its sandboxing that I haven't discovered yet. - Because the package uses classic confinement, it isn't cross-distribution in practice (unfortunately).
Please let me know of any other advantages or disadvantages you think should be listed here.
If you don't trust me to configure your system correctly (which requires sudo):
- All the scripts that make up the sub-commands are visible, e.g. pharo.config can be viewed at /snap/pharo/current/usr/bin/CONFIG
The packaging code is at: https://github.com/akgrant43/pharo-snap
Cheers, Alistair
I need to upgrade to 16.04 now :-) Phil On Tue, Jun 13, 2017 at 11:04 AM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
THANKS A LOT ALISTAIR. I mean it :)
On Tue, Jun 13, 2017 at 10:58 AM, Alistair Grant <akgrant0710@gmail.com> wrote:
Hi Everyone,
I've updated the Pharo 6 snap package for Ubuntu.
The major advantages of using the snap package are:
- No need to install all the 32 bit dependencies on a 64 bit system, they're all contained and isolated within the snap package. - Automagically distinguish between 32 bit and 64 bit images and run the appropriate VM (as with the ZeroConf package, the 64 bit VM still needs more testing).
To get Pharo up and running on Ubuntu 16.04 or later:
# Install Pharo $ sudo snap install --candidate pharo --classic # If your system isn't configured for threaded heartbeat: $ sudo pharo.config # Download the latest Pharo 6 image $ pharo.getimage # Go... $ pharo.ui Pharo.image # or: $ pharo Pharo.image eval 4+3
To get a list of available commands:
$ snap info pharo
If you're on Debian or Ubuntu 14.04 you'll need to install snapd, see https://snapcraft.io/docs/core/install
The VM is the threaded heartbeat, dated 201705310241.
The installation flags are:
--candidate - The edge and beta channels are for development versions. It progresses to candidate and then stable. --classic - Snap packages are normally sandboxed for security reasons. Since Pharo is a development environment in which we want to be able to run any executable, or load any library, it is installed with access to the entire system (as the running user).
Why use snap packages?
- They include all dependencies. In particular, for the 32 bit versions, this means that it isn't necessary to install all the 32 bit architecture and associated dependencies. - Including dependencies means that there shouldn't be any problems with incompatible library versions when upgrading.
Why not use snap packages?
- It's a relatively new technology, with a number of rough edges. - There may still be issues with its sandboxing that I haven't discovered yet. - Because the package uses classic confinement, it isn't cross-distribution in practice (unfortunately).
Please let me know of any other advantages or disadvantages you think should be listed here.
If you don't trust me to configure your system correctly (which requires sudo):
- All the scripts that make up the sub-commands are visible, e.g. pharo.config can be viewed at /snap/pharo/current/usr/bin/CONFIG
The packaging code is at: https://github.com/akgrant43/pharo-snap
Cheers, Alistair
On Tue, Jun 13, 2017 at 11:25:15AM +0200, phil@highoctane.be wrote:
I need to upgrade to 16.04 now :-)
:-) Don't forget you can install snapd on Ubuntu 14.04: https://snapcraft.io/docs/core/install-ubuntu Cheers, Alistair
Phil
On Tue, Jun 13, 2017 at 11:04 AM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
THANKS A LOT ALISTAIR. I mean it :)
On Tue, Jun 13, 2017 at 10:58 AM, Alistair Grant <akgrant0710@gmail.com> wrote: > Hi Everyone, > > I've updated the Pharo 6 snap package for Ubuntu. > > The major advantages of using the snap package are: > > - No need to install all the 32 bit dependencies on a 64 bit system, > they're all contained and isolated within the snap package. > - Automagically distinguish between 32 bit and 64 bit images and run the > appropriate VM (as with the ZeroConf package, the 64 bit VM still > needs more testing). > > > > To get Pharo up and running on Ubuntu 16.04 or later: > > # Install Pharo > $ sudo snap install --candidate pharo --classic > # If your system isn't configured for threaded heartbeat: > $ sudo pharo.config > # Download the latest Pharo 6 image > $ pharo.getimage > # Go... > $ pharo.ui Pharo.image > # or: > $ pharo Pharo.image eval 4+3 > > To get a list of available commands: > > $ snap info pharo > > > If you're on Debian or Ubuntu 14.04 you'll need to install snapd, see > https://snapcraft.io/docs/core/install > > > The VM is the threaded heartbeat, dated 201705310241. > > The installation flags are: > > --candidate - The edge and beta channels are for development versions. > It progresses to candidate and then stable. > --classic - Snap packages are normally sandboxed for security > reasons. Since Pharo is a development environment > in which we want to be able to run any executable, > or load any library, it is installed with access to > the entire system (as the running user). > > Why use snap packages? > > - They include all dependencies. In particular, for the 32 bit > versions, this means that it isn't necessary to install all the 32 bit > architecture and associated dependencies. > - Including dependencies means that there shouldn't be any problems with > incompatible library versions when upgrading. > > Why not use snap packages? > > - It's a relatively new technology, with a number of rough edges. > - There may still be issues with its sandboxing that I haven't > discovered yet. > - Because the package uses classic confinement, it isn't > cross-distribution in practice (unfortunately). > > Please let me know of any other advantages or disadvantages you think > should be listed here. > > If you don't trust me to configure your system correctly (which requires > sudo): > > - All the scripts that make up the sub-commands are visible, e.g. > pharo.config can be viewed at /snap/pharo/current/usr/bin/CONFIG > > > The packaging code is at: https://github.com/akgrant43/pharo-snap > > > Cheers, > Alistair
On Tue, Jun 13, 2017 at 11:34 AM, Alistair Grant <akgrant0710@gmail.com> wrote:
On Tue, Jun 13, 2017 at 11:25:15AM +0200, phil@highoctane.be wrote:
I need to upgrade to 16.04 now :-)
:-)
Don't forget you can install snapd on Ubuntu 14.04:
Ah, wasn't aware of that. Thx Alistair! Phil
Cheers, Alistair
Phil
On Tue, Jun 13, 2017 at 11:04 AM, Stephane Ducasse < stepharo.self@gmail.com> wrote:
THANKS A LOT ALISTAIR. I mean it :)
On Tue, Jun 13, 2017 at 10:58 AM, Alistair Grant < akgrant0710@gmail.com> wrote: > Hi Everyone, > > I've updated the Pharo 6 snap package for Ubuntu. > > The major advantages of using the snap package are: > > - No need to install all the 32 bit dependencies on a 64 bit system, > they're all contained and isolated within the snap package. > - Automagically distinguish between 32 bit and 64 bit images and run the > appropriate VM (as with the ZeroConf package, the 64 bit VM still > needs more testing). > > > > To get Pharo up and running on Ubuntu 16.04 or later: > > # Install Pharo > $ sudo snap install --candidate pharo --classic > # If your system isn't configured for threaded heartbeat: > $ sudo pharo.config > # Download the latest Pharo 6 image > $ pharo.getimage > # Go... > $ pharo.ui Pharo.image > # or: > $ pharo Pharo.image eval 4+3 > > To get a list of available commands: > > $ snap info pharo > > > If you're on Debian or Ubuntu 14.04 you'll need to install snapd, see > https://snapcraft.io/docs/core/install > > > The VM is the threaded heartbeat, dated 201705310241. > > The installation flags are: > > --candidate - The edge and beta channels are for development versions. > It progresses to candidate and then stable. > --classic - Snap packages are normally sandboxed for security > reasons. Since Pharo is a development environment > in which we want to be able to run any executable, > or load any library, it is installed with access to > the entire system (as the running user). > > Why use snap packages? > > - They include all dependencies. In particular, for the 32 bit > versions, this means that it isn't necessary to install all the 32 bit > architecture and associated dependencies. > - Including dependencies means that there shouldn't be any problems with > incompatible library versions when upgrading. > > Why not use snap packages? > > - It's a relatively new technology, with a number of rough edges. > - There may still be issues with its sandboxing that I haven't > discovered yet. > - Because the package uses classic confinement, it isn't > cross-distribution in practice (unfortunately). > > Please let me know of any other advantages or disadvantages you think > should be listed here. > > If you don't trust me to configure your system correctly (which requires > sudo): > > - All the scripts that make up the sub-commands are visible, e.g. > pharo.config can be viewed at /snap/pharo/current/usr/bin/CONFIG > > > The packaging code is at: https://github.com/akgrant43/pharo-snap > > > Cheers, > Alistair
Hello Are there plans to do a Pharo 6.1 snap package in the upcoming months? (Ubuntu 18.04.1) --Hannes On 6/13/17, phil@highoctane.be <phil@highoctane.be> wrote:
On Tue, Jun 13, 2017 at 11:34 AM, Alistair Grant <akgrant0710@gmail.com> wrote:
On Tue, Jun 13, 2017 at 11:25:15AM +0200, phil@highoctane.be wrote:
I need to upgrade to 16.04 now :-)
:-)
Don't forget you can install snapd on Ubuntu 14.04:
Ah, wasn't aware of that. Thx Alistair!
Phil
Cheers, Alistair
Phil
On Tue, Jun 13, 2017 at 11:04 AM, Stephane Ducasse < stepharo.self@gmail.com> wrote:
THANKS A LOT ALISTAIR. I mean it :)
On Tue, Jun 13, 2017 at 10:58 AM, Alistair Grant < akgrant0710@gmail.com> wrote: > Hi Everyone, > > I've updated the Pharo 6 snap package for Ubuntu. > > The major advantages of using the snap package are: > > - No need to install all the 32 bit dependencies on a 64 bit system, > they're all contained and isolated within the snap package. > - Automagically distinguish between 32 bit and 64 bit images and run the > appropriate VM (as with the ZeroConf package, the 64 bit VM still > needs more testing). > > > > To get Pharo up and running on Ubuntu 16.04 or later: > > # Install Pharo > $ sudo snap install --candidate pharo --classic > # If your system isn't configured for threaded heartbeat: > $ sudo pharo.config > # Download the latest Pharo 6 image > $ pharo.getimage > # Go... > $ pharo.ui Pharo.image > # or: > $ pharo Pharo.image eval 4+3 > > To get a list of available commands: > > $ snap info pharo > > > If you're on Debian or Ubuntu 14.04 you'll need to install snapd, see > https://snapcraft.io/docs/core/install > > > The VM is the threaded heartbeat, dated 201705310241. > > The installation flags are: > > --candidate - The edge and beta channels are for development versions. > It progresses to candidate and then stable. > --classic - Snap packages are normally sandboxed for security > reasons. Since Pharo is a development environment > in which we want to be able to run any executable, > or load any library, it is installed with access to > the entire system (as the running user). > > Why use snap packages? > > - They include all dependencies. In particular, for the 32 bit > versions, this means that it isn't necessary to install all the 32 bit > architecture and associated dependencies. > - Including dependencies means that there shouldn't be any problems with > incompatible library versions when upgrading. > > Why not use snap packages? > > - It's a relatively new technology, with a number of rough edges. > - There may still be issues with its sandboxing that I haven't > discovered yet. > - Because the package uses classic confinement, it isn't > cross-distribution in practice (unfortunately). > > Please let me know of any other advantages or disadvantages you think > should be listed here. > > If you don't trust me to configure your system correctly (which requires > sudo): > > - All the scripts that make up the sub-commands are visible, e.g. > pharo.config can be viewed at /snap/pharo/current/usr/bin/CONFIG > > > The packaging code is at: https://github.com/akgrant43/pharo-snap > > > Cheers, > Alistair
Hi, Guille made this one time ago: https://github.com/guillep/pharo-snapcraft <https://github.com/guillep/pharo-snapcraft> cheers, Esteban
On 22 Aug 2018, at 17:19, H. Hirzel <hannes.hirzel@gmail.com> wrote:
Hello
Are there plans to do a Pharo 6.1 snap package in the upcoming months? (Ubuntu 18.04.1)
--Hannes
On 6/13/17, phil@highoctane.be <phil@highoctane.be> wrote:
On Tue, Jun 13, 2017 at 11:34 AM, Alistair Grant <akgrant0710@gmail.com> wrote:
On Tue, Jun 13, 2017 at 11:25:15AM +0200, phil@highoctane.be wrote:
I need to upgrade to 16.04 now :-)
:-)
Don't forget you can install snapd on Ubuntu 14.04:
Ah, wasn't aware of that. Thx Alistair!
Phil
Cheers, Alistair
Phil
On Tue, Jun 13, 2017 at 11:04 AM, Stephane Ducasse < stepharo.self@gmail.com> wrote:
THANKS A LOT ALISTAIR. I mean it :)
On Tue, Jun 13, 2017 at 10:58 AM, Alistair Grant < akgrant0710@gmail.com> wrote:
Hi Everyone,
I've updated the Pharo 6 snap package for Ubuntu.
The major advantages of using the snap package are:
- No need to install all the 32 bit dependencies on a 64 bit system, they're all contained and isolated within the snap package. - Automagically distinguish between 32 bit and 64 bit images and run the appropriate VM (as with the ZeroConf package, the 64 bit VM still needs more testing).
To get Pharo up and running on Ubuntu 16.04 or later:
# Install Pharo $ sudo snap install --candidate pharo --classic # If your system isn't configured for threaded heartbeat: $ sudo pharo.config # Download the latest Pharo 6 image $ pharo.getimage # Go... $ pharo.ui Pharo.image # or: $ pharo Pharo.image eval 4+3
To get a list of available commands:
$ snap info pharo
If you're on Debian or Ubuntu 14.04 you'll need to install snapd, see https://snapcraft.io/docs/core/install
The VM is the threaded heartbeat, dated 201705310241.
The installation flags are:
--candidate - The edge and beta channels are for development versions. It progresses to candidate and then stable. --classic - Snap packages are normally sandboxed for security reasons. Since Pharo is a development environment in which we want to be able to run any executable, or load any library, it is installed with access to the entire system (as the running user).
Why use snap packages?
- They include all dependencies. In particular, for the 32 bit versions, this means that it isn't necessary to install all the 32 bit architecture and associated dependencies. - Including dependencies means that there shouldn't be any problems with incompatible library versions when upgrading.
Why not use snap packages?
- It's a relatively new technology, with a number of rough edges. - There may still be issues with its sandboxing that I haven't discovered yet. - Because the package uses classic confinement, it isn't cross-distribution in practice (unfortunately).
Please let me know of any other advantages or disadvantages you think should be listed here.
If you don't trust me to configure your system correctly (which requires sudo):
- All the scripts that make up the sub-commands are visible, e.g. pharo.config can be viewed at /snap/pharo/current/usr/bin/CONFIG
The packaging code is at: https://github.com/akgrant43/pharo-snap
Cheers, Alistair
Hi Hannes, On Wed, 22 Aug 2018 at 17:20, H. Hirzel <hannes.hirzel@gmail.com> wrote:
Hello
Are there plans to do a Pharo 6.1 snap package in the upcoming months? (Ubuntu 18.04.1)
I haven't been thinking about it really, because: - The big attraction for me was the ability to easily run 32 bit Pharo on a 64 bit OS without installing all the dependencies. But now that 64 bit Pharo is stable that driver has largely gone. - The sandboxing is quite limiting for a development environment, so if you want to run commands on the localhost you end up doing something like ssh'ing the command to localhost. - The snap runtime environment is still quite immature - I've had to deal with bugs in snapd, the gtk desktop interface, loading 32 bit executables, etc. - The snapcraft build environment is still evolving, so I have to keep up with the changes. - I was originally compiling the 32 and 64 bit VMs as part of the build process, but that is problematic as the 32 and 64 bit libraries tend to interfere with each other making the build process unstable. - You can't run multiple versions of a snap on one system, e.g. we can't have Pharo 6 and Pharo 7 installed simultaneously under the one snap name (pharo). I tried to register Pharo7 so pharo could be the GA version (6), but never got a response. I was listening to an Ubuntu podcast just this week where one of the hosts tried installing 4 packages via snaps and ended up going back to debian packages for 3 of the packages due to problems, so it obviously still isn't mature. I realise that every software package has its own issues, I'm sure someone from the snap community could find parallel issues with Pharo, but it wasn't where I wanted to be spending all my time. If someone wants to take it over, I'm more than happy to pass it on (although it isn't building at the moment due to changes in snapcraft). If there is enough interest I'll try and update it to run Pharo 6.1. If Guille is actively maintaining his package, maybe we should move to that (I haven't looked at it). Cheers, Alistair
Hello Alistair Thank you for the detailed answer. I understand that at the moment going for a Pharo snap package does not seem to be useful. In particular as a Pharo installation may reside in a directory with everything included. So different Pharo installations may reside in different directories. I think where snap still might come is for solutions which require more than a particular Pharo installation. For example I could think of combining a particular Pharo version with a particular Jupyter notebook installation into a snap which could lead to a web based 'Dynabook' solution. I am also looking forward to Guille's answer. Regards Hannes On 8/23/18, Alistair Grant <akgrant0710@gmail.com> wrote:
Hi Hannes,
On Wed, 22 Aug 2018 at 17:20, H. Hirzel <hannes.hirzel@gmail.com> wrote:
Hello
Are there plans to do a Pharo 6.1 snap package in the upcoming months? (Ubuntu 18.04.1)
I haven't been thinking about it really, because:
- The big attraction for me was the ability to easily run 32 bit Pharo on a 64 bit OS without installing all the dependencies. But now that 64 bit Pharo is stable that driver has largely gone. - The sandboxing is quite limiting for a development environment, so if you want to run commands on the localhost you end up doing something like ssh'ing the command to localhost. - The snap runtime environment is still quite immature - I've had to deal with bugs in snapd, the gtk desktop interface, loading 32 bit executables, etc. - The snapcraft build environment is still evolving, so I have to keep up with the changes. - I was originally compiling the 32 and 64 bit VMs as part of the build process, but that is problematic as the 32 and 64 bit libraries tend to interfere with each other making the build process unstable. - You can't run multiple versions of a snap on one system, e.g. we can't have Pharo 6 and Pharo 7 installed simultaneously under the one snap name (pharo). I tried to register Pharo7 so pharo could be the GA version (6), but never got a response.
I was listening to an Ubuntu podcast just this week where one of the hosts tried installing 4 packages via snaps and ended up going back to debian packages for 3 of the packages due to problems, so it obviously still isn't mature.
I realise that every software package has its own issues, I'm sure someone from the snap community could find parallel issues with Pharo, but it wasn't where I wanted to be spending all my time.
If someone wants to take it over, I'm more than happy to pass it on (although it isn't building at the moment due to changes in snapcraft).
If there is enough interest I'll try and update it to run Pharo 6.1.
If Guille is actively maintaining his package, maybe we should move to that (I haven't looked at it).
Cheers, Alistair
Hi Hannes, On Fri, 24 Aug 2018 at 06:36, H. Hirzel <hannes.hirzel@gmail.com> wrote:
Hello Alistair
Thank you for the detailed answer. I understand that at the moment going for a Pharo snap package does not seem to be useful.
In particular as a Pharo installation may reside in a directory with everything included. So different Pharo installations may reside in different directories.
Yep. Especially if using the in-development version of Pharo (currently 7), I find it useful to pair images and VMs.
I think where snap still might come is for solutions which require more than a particular Pharo installation.
For example I could think of combining a particular Pharo version with a particular Jupyter notebook installation into a snap which could lead to a web based 'Dynabook' solution.
That was one of the things that attracted me to snaps originally, I use sqlite in my daily environment, so included it in the Pharo snap.
I am also looking forward to Guille's answer.
+1. Cheers, Alistair
Regards Hannes
On 8/23/18, Alistair Grant <akgrant0710@gmail.com> wrote:
Hi Hannes,
On Wed, 22 Aug 2018 at 17:20, H. Hirzel <hannes.hirzel@gmail.com> wrote:
Hello
Are there plans to do a Pharo 6.1 snap package in the upcoming months? (Ubuntu 18.04.1)
I haven't been thinking about it really, because:
- The big attraction for me was the ability to easily run 32 bit Pharo on a 64 bit OS without installing all the dependencies. But now that 64 bit Pharo is stable that driver has largely gone. - The sandboxing is quite limiting for a development environment, so if you want to run commands on the localhost you end up doing something like ssh'ing the command to localhost. - The snap runtime environment is still quite immature - I've had to deal with bugs in snapd, the gtk desktop interface, loading 32 bit executables, etc. - The snapcraft build environment is still evolving, so I have to keep up with the changes. - I was originally compiling the 32 and 64 bit VMs as part of the build process, but that is problematic as the 32 and 64 bit libraries tend to interfere with each other making the build process unstable. - You can't run multiple versions of a snap on one system, e.g. we can't have Pharo 6 and Pharo 7 installed simultaneously under the one snap name (pharo). I tried to register Pharo7 so pharo could be the GA version (6), but never got a response.
I was listening to an Ubuntu podcast just this week where one of the hosts tried installing 4 packages via snaps and ended up going back to debian packages for 3 of the packages due to problems, so it obviously still isn't mature.
I realise that every software package has its own issues, I'm sure someone from the snap community could find parallel issues with Pharo, but it wasn't where I wanted to be spending all my time.
If someone wants to take it over, I'm more than happy to pass it on (although it isn't building at the moment due to changes in snapcraft).
If there is enough interest I'll try and update it to run Pharo 6.1.
If Guille is actively maintaining his package, maybe we should move to that (I haven't looked at it).
Cheers, Alistair
Hi all, Nope, I'm not maintaining my package. I was experimenting with it at some point (2 years ago?) and then saw somebody else started with a more complete solution so I've not continued working on it. Personally, I've experienced the same sandboxing problems stated by Alistair, plus the fact that at that moment Snap was not working in *nixes other than Ubuntu made me put my energy somewhere else. Three points more: - for those that do not know exactly what we are talking about, snap is "new" a packaging tool used in ubuntu. I strongly believe that we could use some kind of tool like this for the VM, but not for image (which are mutable). - it could maybe make more sense to package the pharo launcher? ;) - rather than snaps, I'd put my 2cents on a solution like https://github.com/probonopd/appimagekit/. I've been following it for two years and it has a lot of movement and getting mature. On Fri, Aug 24, 2018 at 6:18 PM Alistair Grant <akgrant0710@gmail.com> wrote:
Hi Hannes,
On Fri, 24 Aug 2018 at 06:36, H. Hirzel <hannes.hirzel@gmail.com> wrote:
Hello Alistair
Thank you for the detailed answer. I understand that at the moment going for a Pharo snap package does not seem to be useful.
In particular as a Pharo installation may reside in a directory with everything included. So different Pharo installations may reside in different directories.
Yep. Especially if using the in-development version of Pharo (currently 7), I find it useful to pair images and VMs.
I think where snap still might come is for solutions which require more than a particular Pharo installation.
For example I could think of combining a particular Pharo version with a particular Jupyter notebook installation into a snap which could lead to a web based 'Dynabook' solution.
That was one of the things that attracted me to snaps originally, I use sqlite in my daily environment, so included it in the Pharo snap.
I am also looking forward to Guille's answer.
+1.
Cheers, Alistair
Regards Hannes
On 8/23/18, Alistair Grant <akgrant0710@gmail.com> wrote:
Hi Hannes,
On Wed, 22 Aug 2018 at 17:20, H. Hirzel <hannes.hirzel@gmail.com> wrote:
Hello
Are there plans to do a Pharo 6.1 snap package in the upcoming months? (Ubuntu 18.04.1)
I haven't been thinking about it really, because:
- The big attraction for me was the ability to easily run 32 bit Pharo on a 64 bit OS without installing all the dependencies. But now that 64 bit Pharo is stable that driver has largely gone. - The sandboxing is quite limiting for a development environment, so if you want to run commands on the localhost you end up doing something like ssh'ing the command to localhost. - The snap runtime environment is still quite immature - I've had to deal with bugs in snapd, the gtk desktop interface, loading 32 bit executables, etc. - The snapcraft build environment is still evolving, so I have to keep up with the changes. - I was originally compiling the 32 and 64 bit VMs as part of the build process, but that is problematic as the 32 and 64 bit libraries tend to interfere with each other making the build process unstable. - You can't run multiple versions of a snap on one system, e.g. we can't have Pharo 6 and Pharo 7 installed simultaneously under the one snap name (pharo). I tried to register Pharo7 so pharo could be the GA version (6), but never got a response.
I was listening to an Ubuntu podcast just this week where one of the hosts tried installing 4 packages via snaps and ended up going back to debian packages for 3 of the packages due to problems, so it obviously still isn't mature.
I realise that every software package has its own issues, I'm sure someone from the snap community could find parallel issues with Pharo, but it wasn't where I wanted to be spending all my time.
If someone wants to take it over, I'm more than happy to pass it on (although it isn't building at the moment due to changes in snapcraft).
If there is enough interest I'll try and update it to run Pharo 6.1.
If Guille is actively maintaining his package, maybe we should move to that (I haven't looked at it).
Cheers, Alistair
-- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13
Hi, Another project that have save us from installation pains on several heterogeneous environments while giving workshops (including machines with several Linux flavors and Mac OS X, but not Windows) is Nix[1]. There is even a package for Pharo[2]. [1] https://nixos.org/nix/ [2] https://nixos.org/releases/tmp/release-nixos-unstable-small/nixos-18.09pre13... Cheers, Offray On 9/7/18 10:07 AM, Guillermo Polito wrote:
Hi all,
Nope, I'm not maintaining my package. I was experimenting with it at some point (2 years ago?) and then saw somebody else started with a more complete solution so I've not continued working on it.
Personally, I've experienced the same sandboxing problems stated by Alistair, plus the fact that at that moment Snap was not working in *nixes other than Ubuntu made me put my energy somewhere else.
Three points more:  - for those that do not know exactly what we are talking about, snap is "new" a packaging tool used in ubuntu. I strongly believe that we could use some kind of tool like this for the VM, but not for image (which are mutable).  - it could maybe make more sense to package the pharo launcher? ;)  - rather than snaps, I'd put my 2cents on a solution like https://github.com/probonopd/appimagekit/. I've been following it for two years and it has a lot of movement and getting mature.
On Fri, Aug 24, 2018 at 6:18 PM Alistair Grant <akgrant0710@gmail.com <mailto:akgrant0710@gmail.com>> wrote:
Hi Hannes,
On Fri, 24 Aug 2018 at 06:36, H. Hirzel <hannes.hirzel@gmail.com <mailto:hannes.hirzel@gmail.com>> wrote: > > Hello Alistair > > Thank you for the detailed answer. I understand that at the moment > going for a Pharo snap package does not seem to be useful. > > In particular as a Pharo installation may reside in a directory with > everything included. > So different Pharo installations may reside in different directories.
Yep. Especially if using the in-development version of Pharo (currently 7), I find it useful to pair images and VMs.
> I think where snap still might come is for solutions which require > more than a particular Pharo installation. > > For example I could think of combining a particular Pharo version with > a particular Jupyter notebook installation into a snap which could > lead to a web based 'Dynabook' solution.
That was one of the things that attracted me to snaps originally, I use sqlite in my daily environment, so included it in the Pharo snap.
> I am also looking forward to Guille's answer.
+1.
Cheers, Alistair
> Regards > Hannes > > On 8/23/18, Alistair Grant <akgrant0710@gmail.com <mailto:akgrant0710@gmail.com>> wrote: > > Hi Hannes, > > > > On Wed, 22 Aug 2018 at 17:20, H. Hirzel <hannes.hirzel@gmail.com <mailto:hannes.hirzel@gmail.com>> wrote: > >> > >> Hello > >> > >> Are there plans to do a Pharo 6.1 snap package in the upcoming > >> months? (Ubuntu 18.04.1) > > > > I haven't been thinking about it really, because: > > > > - The big attraction for me was the ability to easily run 32 bit Pharo > > on a 64 bit OS without installing all the dependencies. But now that > > 64 bit Pharo is stable that driver has largely gone. > > - The sandboxing is quite limiting for a development environment, so > > if you want to run commands on the localhost you end up doing > > something like ssh'ing the command to localhost. > > - The snap runtime environment is still quite immature - I've had to > > deal with bugs in snapd, the gtk desktop interface, loading 32 bit > > executables, etc. > > - The snapcraft build environment is still evolving, so I have to keep > > up with the changes. > > - I was originally compiling the 32 and 64 bit VMs as part of the > > build process, but that is problematic as the 32 and 64 bit libraries > > tend to interfere with each other making the build process unstable. > > - You can't run multiple versions of a snap on one system, e.g. we > > can't have Pharo 6 and Pharo 7 installed simultaneously under the one > > snap name (pharo). I tried to register Pharo7 so pharo could be the > > GA version (6), but never got a response. > > > > I was listening to an Ubuntu podcast just this week where one of the > > hosts tried installing 4 packages via snaps and ended up going back to > > debian packages for 3 of the packages due to problems, so it obviously > > still isn't mature. > > > > I realise that every software package has its own issues, I'm sure > > someone from the snap community could find parallel issues with Pharo, > > but it wasn't where I wanted to be spending all my time. > > > > If someone wants to take it over, I'm more than happy to pass it on > > (although it isn't building at the moment due to changes in > > snapcraft). > > > > If there is enough interest I'll try and update it to run Pharo 6.1. > > > > If Guille is actively maintaining his package, maybe we should move to > > that (I haven't looked at it). > > > > Cheers, > > Alistair
--
  Â
Guille Polito
Research Engineer
Centre de Recherche en Informatique, Signal et Automatique de Lille
CRIStAL - UMR 9189
French National Center for Scientific Research - _http://www.cnrs.fr_
*Web:* _http://guillep.github.io_
*Phone: *+33 06 52 70 66 13
On Tue, Jun 13, 2017 at 08:58:31AM +0000, Alistair Grant wrote:
Hi Everyone,
I've updated the Pharo 6 snap package for Ubuntu.
The major advantages of using the snap package are:
- No need to install all the 32 bit dependencies on a 64 bit system, they're all contained and isolated within the snap package. - Automagically distinguish between 32 bit and 64 bit images and run the appropriate VM (as with the ZeroConf package, the 64 bit VM still needs more testing).
To get Pharo up and running on Ubuntu 16.04 or later:
# Install Pharo $ sudo snap install --candidate pharo --classic # If your system isn't configured for threaded heartbeat: $ sudo pharo.config # Download the latest Pharo 6 image $ pharo.getimage
I should have added if you want the 32 bit image: $ pharo.getimage32 the rest remains the same
# Go... $ pharo.ui Pharo.image # or: $ pharo Pharo.image eval 4+3
To get a list of available commands:
$ snap info pharo
If you're on Debian or Ubuntu 14.04 you'll need to install snapd, see https://snapcraft.io/docs/core/install
The VM is the threaded heartbeat, dated 201705310241.
The installation flags are:
--candidate - The edge and beta channels are for development versions. It progresses to candidate and then stable. --classic - Snap packages are normally sandboxed for security reasons. Since Pharo is a development environment in which we want to be able to run any executable, or load any library, it is installed with access to the entire system (as the running user).
Why use snap packages?
- They include all dependencies. In particular, for the 32 bit versions, this means that it isn't necessary to install all the 32 bit architecture and associated dependencies. - Including dependencies means that there shouldn't be any problems with incompatible library versions when upgrading.
Why not use snap packages?
- It's a relatively new technology, with a number of rough edges. - There may still be issues with its sandboxing that I haven't discovered yet. - Because the package uses classic confinement, it isn't cross-distribution in practice (unfortunately).
Please let me know of any other advantages or disadvantages you think should be listed here.
If you don't trust me to configure your system correctly (which requires sudo):
- All the scripts that make up the sub-commands are visible, e.g. pharo.config can be viewed at /snap/pharo/current/usr/bin/CONFIG
The packaging code is at: https://github.com/akgrant43/pharo-snap
Cheers, Alistair
participants (7)
-
Alistair Grant -
Esteban Lorenzano -
Guillermo Polito -
H. Hirzel -
Offray Vladimir Luna Cárdenas -
phil＠highoctane.be -
Stephane Ducasse