On 23 February 2017 at 19:34, Stuart Bishop wrote:
> 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 loo
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 example snap that uses the
> conten
On 23 February 2017 at 14:39, Stuart Bishop wrote:
> 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 w
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 ~/.local/lib/..., or t
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 interesting to see, but my t
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 dif
On Feb 21, 2017, at 07:35 PM, James Henstridge wrote:
>It probably wouldn't be too difficult to build a snap tracking 3.7
>development, yeah.
Now that CPython development has moved to GitHub, I wonder if this isn't
something we could automate, with a mirror on Launchpad.
On Feb 21, 2017, at 07:5
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
>>> would stick to using virtualenvs
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 root. Although most devs
>>> would stick to using virtualenvs outs
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,
>> assuming a modern enough Python
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 example showing how to reduce a python snap package. A
>>> few days ago, I also made a smal
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 example to make use of the python3 coming
>> with the core
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 example to make use of the python3 coming
> with the core at:
>
> https://github.com/liu-xiao-guo/httpstat
>
> In the ab
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 release,
> say 4.0.
I've inc
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.
Thank
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 interp
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.
Now
17 matches
Mail list logo
