On 14/12/2016 00:42, Kyle Evans wrote:
On Tue, Dec 13, 2016 at 4:59 AM, Kubilay Kocak wrote:
Note that they will be re-created on import unless one overrides the
default for the interpreter to produce these optimization files.
I'm not sure (or cant remember) if there is a good way to disable
On Tue, Dec 13, 2016 at 4:59 AM, Kubilay Kocak wrote:
>
> Note that they will be re-created on import unless one overrides the
> default for the interpreter to produce these optimization files.
>
> I'm not sure (or cant remember) if there is a good way to disable this
> on a global or system-wide
On 12/13/2016 12:55:40 PM, "Vlad K." wrote:
On 2016-12-13 12:36, Kubilay Kocak wrote:
My main point was that if disk utilisation is something one wants to
minimise (at deployment), that one would need to be able to turn the
optimization knob off each time (or system-wide) and that that woul
On 12/13/2016 11:59:32 AM, "Kubilay Kocak" wrote:
[...]
I'm not sure (or cant remember) if there is a good way to disable this
on a global or system-wide basis.
There are some environmental settings offered by Python to avoid
creating
byte-compiled and optimized cache files. It's up to the e
On 2016-12-13 12:36, Kubilay Kocak wrote:
My main point was that if disk utilisation is something one wants to
minimise (at deployment), that one would need to be able to turn the
optimization knob off each time (or system-wide) and that that would be
a handy thing to know and do.
Personally,
On 13/12/2016 10:08 PM, Vlad K. wrote:
> On 2016-12-13 11:59, Kubilay Kocak wrote:
>>
>> Note that they will be re-created on import unless one overrides
>> the default for the interpreter to produce these optimization
>> files.
>
> Depends. Those modules are installed in a root owned directory,
On 2016-12-13 11:59, Kubilay Kocak wrote:
Note that they will be re-created on import unless one overrides the
default for the interpreter to produce these optimization files.
Depends. Those modules are installed in a root owned directory, and the
bytecode cache will get created only if you r
On 13/12/2016 9:13 AM, Kyle Evans wrote:
> On Mon, Dec 12, 2016 at 3:51 PM, Marcus von Appen
> wrote:
>> Hi Kyle,
>>
>>> [snip]
>>
>> this is a python3 specific change in how python deals with
>> optimized bytecode files. We ship .pyc/.pyo files for python2 ports
>> and __pycache__ bits for pyth
On Mon, Dec 12, 2016 at 3:51 PM, Marcus von Appen wrote:
> Hi Kyle,
>
>> [snip]
>
> this is a python3 specific change in how python deals with optimized
> bytecode files.
> We ship .pyc/.pyo files for python2 ports and __pycache__ bits for python3,
> so there
> is no change in packaging behaviour
Hi Kyle,
On 12/12/2016 7:54:18 PM, "Kyle Evans" wrote:
Hello!
Out of curiosity, is there a specific reason that the lang/python3*
ports all include various __pycache__ bits while these were not
present, at least, in lang/python27?
this is a python3 specific change in how python deals with opt
Hello!
Out of curiosity, is there a specific reason that the lang/python3*
ports all include various __pycache__ bits while these were not
present, at least, in lang/python27?
I ask because this seems to be a decent amount of fat added to the
resulting packages that I'd rather not have in the env
11 matches
Mail list logo
