*.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