Re: Experimental Python interpreter snap

On 23 February 2017 at 14:45, James Henstridge wrote: > So if I installed a package to $SNAP_USER_DATA for my > "python36-jamesh.python3" interpreter, the files would end up > somewhere under ~/snap/python36-jamesh/. > > If we then look at my simple hello-world

Re: Experimental Python interpreter snap

On 22 February 2017 at 21:47, James Henstridge wrote: > Yep. So I think it probably makes most sense for the Python runtime > snap to default to classic confinement so that it behaves as a user > would expect for interactive/development work, with pip ready to > install to

Re: Experimental Python interpreter snap

On 21 February 2017 at 23:37, Barry Warsaw wrote: > On Feb 21, 2017, at 09:30 PM, James Henstridge wrote: > >>So we might be able to do a single package that can both serve as a >>runtime for other snaps and as a useful Python development >>environment. > > It would be

Re: Experimental Python interpreter snap

On Feb 21, 2017, at 09:30 PM, James Henstridge wrote: >So we might be able to do a single package that can both serve as a >runtime for other snaps and as a useful Python development >environment. It would be interesting to see, but my tendency is to want separate interpreter environments for

Re: Experimental Python interpreter snap

On Tue, 21 Feb 2017 19:53:31 +0700, Stuart Bishop wrote: > On 21 February 2017 at 18:35, James Henstridge > wrote: > >>> You could probably also get the pip in your snap to install packages >>> to $SNAP_USER_DATA or $SNAP_DATA if run as root. Although most devs >>>

Re: Experimental Python interpreter snap

On 21 February 2017 at 20:53, Stuart Bishop wrote: > On 21 February 2017 at 18:35, James Henstridge > wrote: > >>> You could probably also get the pip in your snap to install packages >>> to $SNAP_USER_DATA or $SNAP_DATA if run as

Re: Experimental Python interpreter snap

On 21 February 2017 at 18:35, James Henstridge wrote: >> You could probably also get the pip in your snap to install packages >> to $SNAP_USER_DATA or $SNAP_DATA if run as root. Although most devs >> would stick to using virtualenvs outside of the snap for this,

Re: Experimental Python interpreter snap

On 21 February 2017 at 16:57, Stuart Bishop wrote: > On 20 February 2017 at 11:41, James Henstridge > wrote: >> On 20 February 2017 at 10:45, XiaoGuo Liu wrote: >>> Hi James, >>> >>> Nice. This is a nice

Re: Experimental Python interpreter snap

On 20 February 2017 at 11:41, James Henstridge wrote: > On 20 February 2017 at 10:45, XiaoGuo Liu wrote: >> Hi James, >> >> Nice. This is a nice example showing how to reduce a python snap package. A >> few days ago, I also made a small

Re: Experimental Python interpreter snap

On 20 February 2017 at 10:41, Spencer wrote: > I thought a main feature of snaps was to include all dependencies so that > they couldn't be changed out from underneath a package. For example, my > script was written for 3.6, but would be incompatible with a future

Re: Experimental Python interpreter snap

Hi James, Nice. This is a nice example showing how to reduce a python snap package. A few days ago, I also made a small example to make use of the python3 coming with the core at: https://github.com/liu-xiao-guo/httpstat In the above example, I in fact do not package the python. It works.

Re: Experimental Python interpreter snap

I thought a main feature of snaps was to include all dependencies so that they couldn't be changed out from underneath a package. For example, my script was written for 3.6, but would be incompatible with a future release, say 4.0. Still, the ability to share a dependency like the Python

Experimental Python interpreter snap

To learn a bit more about I put together a snap for Python 3.6.0, which can be installed with: snap install --edge python36-jamesh You can then run "python36-jamesh.python3", which will give you the a Python shell running with strict confinement, with the full standard library available.