*.py packaging, again
Jeff Johnson
n3npq at mac.com
Thu Jul 14 22:51:07 CEST 2011
On Jul 14, 2011, at 3:52 PM, Artur Wroblewski wrote:
> On Thu, Jul 14, 2011 at 8:26 PM, Jeff Johnson <n3npq at mac.com> wrote:
>>
>> On Jul 14, 2011, at 2:31 PM, Artur Wroblewski wrote:
>>
>>> On Thu, Jul 14, 2011 at 8:44 AM, Jacek Konieczny <jajcus at jajcus.net> wrote:
>>> [...]
>>>> We lose:
>>>> - a little bit of the disk space
>>>> - some 'purity' some people see in not distributing 'sources'
>>>
>>> IMHO, it was not about purity but quite practical aspect of
>>> file distribution (src vs. bin) - we treated byte compiled files
>>> for Java and Python the same way, no src allowed.
>>>
>>
>> All depends on what you want to emphasize in the comparison.
>>
>> E.g. man pages are generated and cached and none is
>> asking for support from RPM for handling "ownership"
>> and integrity of the generated man pages. The ached aspects
>> of __pycache__ aren't that different (but are executable so
>> the audit is more complex than for data files).
>
> Sure. I just re-stated our approach we took in the past.
>
And no offense intended: truly there's a balance point to
handle __pycache__ registration here somehow/somwhere.
I merely wished to point out one of the extrema constraints:
Don't bother handling __pycache__ at all, treat like
cached man pages.
I don't know what the right/best answer is. I do trust PLD will
find a sane answer first. There's no other distro around attempting
python-3.x packaging that I've heard/seen yet.
73 de Jeff
> Best regards,
>
> w
> _______________________________________________
> pld-devel-en mailing list
> pld-devel-en at lists.pld-linux.org
> http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
More information about the pld-devel-en
mailing list