On Fri, May 20, 2011 at 11:34 AM, Jacek Konieczny jaj...@jajcus.net wrote:
Maybe we should have some automation for packaging (or not
packaging) __pycache__ and its contents? So it doesn't have to be listed
explicitly for every python package. I am thinking about something like
%find_lang –
On Sat, May 21, 2011 at 12:22:04PM +0100, Artur Wroblewski wrote:
On Fri, May 20, 2011 at 11:34 AM, Jacek Konieczny jaj...@jajcus.net wrote:
Maybe we should have some automation for packaging (or not
packaging) __pycache__ and its contents? So it doesn't have to be listed
explicitly for
On Thu, May 19, 2011 at 6:08 PM, Artur Wroblewski wrob...@pld-linux.org wrote:
[...]
Anyway, if no one objects then I will finish packaging of Python 3.2
during the weekend using source files and __pycache__.
Done.
I have upgraded few packages, too. Some of them are not done
in nice way (i.e.
On Sat, May 21, 2011 at 1:12 PM, Jacek Konieczny jaj...@jajcus.net wrote:
On Sat, May 21, 2011 at 12:22:04PM +0100, Artur Wroblewski wrote:
On Fri, May 20, 2011 at 11:34 AM, Jacek Konieczny jaj...@jajcus.net wrote:
Maybe we should have some automation for packaging (or not
packaging)
On Thu, May 19, 2011 at 06:08:31PM +0100, Artur Wroblewski wrote:
There is also
http://web.archiveorange.com/archive/v/jA6s9GD0sh2vKRhR2zat
to study.
We could also think about zipping of the modules later...
Anyway, if no one objects then I will finish packaging of Python 3.2
On Fri, May 20, 2011 at 12:34:44PM +0200, Jacek Konieczny wrote:
On Thu, May 19, 2011 at 06:08:31PM +0100, Artur Wroblewski wrote:
There is also
http://web.archiveorange.com/archive/v/jA6s9GD0sh2vKRhR2zat
to study.
We could also think about zipping of the modules later...
On Sat, Apr 2, 2011 at 7:11 PM, Jakub Bogusz qbo...@pld-linux.org wrote:
[...]
So we have to decide how to package python distribution (and possibly
all python3 modules, if distutils use __pycache__ too) - there are
two solutions:
- package all modules in source form together with __pycache__
There is also
http://web.archiveorange.com/archive/v/jA6s9GD0sh2vKRhR2zat
to study.
We could also think about zipping of the modules later...
Anyway, if no one objects then I will finish packaging of Python 3.2
during the weekend using source files and __pycache__.
Is that OK?
Regards,
w
On 09.04.2011 22:03, Jan Rękorajski wrote:
On Sat, 09 Apr 2011, Elan Ruusamäe wrote:
as for the .py sources packaging, i'd move them to -debuginfo package so
the could be installed optionally
Are you aware that some python apps do runtime feature checking and
setting based od the presence of
On Sat, Apr 09, 2011 at 09:03:44PM +0200, Jan Rękorajski wrote:
On Sat, 09 Apr 2011, Elan Ruusamäe wrote:
as for the .py sources packaging, i'd move them to -debuginfo package so
the could be installed optionally
Are you aware that some python apps do runtime feature checking and
2011/4/10 Jakub Bogusz qbo...@pld-linux.org:
On Sat, Apr 09, 2011 at 09:03:44PM +0200, Jan Rękorajski wrote:
On Sat, 09 Apr 2011, Elan Ruusamäe wrote:
as for the .py sources packaging, i'd move them to -debuginfo package so
the could be installed optionally
Are you aware that some python
2011/4/9 Elan Ruusamäe g...@pld-linux.org:
so my vote goes for keeping the old .py[co] method, and perhaps change to
make is package only .pyc, it is rather ratre somebody invokes python with
-O option so the .pyo is to be needed. or why it was packaged in first
place? to get files owned in
On Sat, 09 Apr 2011, Elan Ruusamäe wrote:
as for the .py sources packaging, i'd move them to -debuginfo package so
the could be installed optionally
Are you aware that some python apps do runtime feature checking and
setting based od the presence of .py files? That those apps can't live
On Apr 9, 2011, at 2:13 PM, Patryk Zawadzki wrote:
2011/4/9 Elan Ruusamäe g...@pld-linux.org:
so my vote goes for keeping the old .py[co] method, and perhaps change to
make is package only .pyc, it is rather ratre somebody invokes python with
-O option so the .pyo is to be needed. or why it
On Sat, Apr 09, 2011 at 15:26:46 -0400, Jeff Johnson wrote:
There's no known reason why xattr's can't be done in other ways.
Like what?
--
Tomasz Pala go...@pld-linux.org
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
On Apr 9, 2011, at 3:29 PM, Tomasz Pala wrote:
On Sat, Apr 09, 2011 at 15:26:46 -0400, Jeff Johnson wrote:
There's no known reason why xattr's can't be done in other ways.
Like what?
Like not having RPM attach xattr's. 5+ years ago, I had
to swipe a hunk of code from libselinux and get
On Sat, Apr 09, 2011 at 15:34:55 -0400, Jeff Johnson wrote:
There's no known reason why xattr's can't be done in other ways.
Like what?
Like not having RPM attach xattr's.
Please tell me how to do root-free (capabilities-based) system without
xattrs in rpm - doing this outside upgrade
On Apr 9, 2011, at 3:50 PM, Tomasz Pala wrote:
On Sat, Apr 09, 2011 at 15:34:55 -0400, Jeff Johnson wrote:
There's no known reason why xattr's can't be done in other ways.
Like what?
Like not having RPM attach xattr's.
Please tell me how to do root-free (capabilities-based) system
On Sat, Apr 09, 2011 at 16:32:01 -0400, Jeff Johnson wrote:
And I've shown that this way is wrong - having xattrs outside package
manager is bad design per se.
You WILL have users using python eggs, and there WILL be a window
installing content outside of package management.
And how is
On Apr 9, 2011, at 4:52 PM, Tomasz Pala wrote:
On Sat, Apr 09, 2011 at 16:32:01 -0400, Jeff Johnson wrote:
And I've shown that this way is wrong - having xattrs outside package
manager is bad design per se.
You WILL have users using python eggs, and there WILL be a window
installing
On Apr 9, 2011, at 6:49 PM, Tomasz Pala wrote:
On Sat, Apr 09, 2011 at 17:09:54 -0400, Jeff Johnson wrote:
And I'm not disagreeing. How rpm should handle xattr's like
that capabilities you want is a whole different matter.
Attaching Yet Another per-file tag everywhere just to set
a
On Sat, Apr 09, 2011 at 19:05:33 -0400, Jeff Johnson wrote:
FOr a distro containing 1M files, empty string tags require (at least) '\0'.
But ~1Mb (for a 1M file distro) additional info is moderately significant. Go
look at
ls -al /var/lib/rpm/Packages
run
rpm -qal | wc -l
On Apr 9, 2011, at 7:38 PM, Tomasz Pala wrote:
On Sat, Apr 09, 2011 at 19:05:33 -0400, Jeff Johnson wrote:
FOr a distro containing 1M files, empty string tags require (at least) '\0'.
But ~1Mb (for a 1M file distro) additional info is moderately significant.
Go look at
ls -al
On Sat, Apr 09, 2011 at 19:52:34 -0400, Jeff Johnson wrote:
SO add the tag. I can't justify the implementation for lots of reasons,
not only space. I answered what the overhead cost was, not what the
complexity cost is/was.
Once again you write about 'some reasons' and keep them for yourself,
On Apr 9, 2011, at 8:36 PM, Tomasz Pala wrote:
BTW it's you who wrote we've got good engineering practices often.
Let's just leave it here:
PLD is my favorite distro, solves problems (like *.pyo files
changing in python 3.2+), devises fixes, and moves on
months and
On Mon, Apr 4, 2011 at 6:58 AM, Jakub Bogusz qbo...@pld-linux.org wrote:
Who is going to clean ~/.local/cache for files removed from system?
Why would _system_ packages end up being compiled to ~/.local/cache?
Also, I'm against compiling python files during installation of rpm package.
Python
On Sun, Apr 3, 2011 at 2:21 PM, Bartosz Taudul wolf@gmail.com wrote:
On Sun, Apr 3, 2011 at 3:29 AM, Patryk Zawadzki pat...@pld-linux.org wrote:
I would opt for this solution. We had many problems previously due to
removing
py files and py files are very usefull when debugging or working
On Apr 3, 2011, at 8:38 AM, Patryk Zawadzki wrote:
and sources are often the only source of (up to date)
documentation.
So the source code is the documentation. What else is new? Are you
simply trolling, or just are too ignorant to be aware that's also what
happens with all other
On Saturday 02 of April 2011, Jakub Bogusz wrote:
- package all modules in source form together with __pycache__
subdirectories
+1
--mmazur
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
On Sun, Apr 03, 2011 at 02:38:49PM +0200, Patryk Zawadzki wrote:
Except in Python you can execute/import .py files just fine. If the
program is not closed source, .pyc/.pyo/__pycache__ are just an
optimization detail. We could very well create them in %post.
That is a very bad idea. Bad things
On Apr 3, 2011, at 9:00 AM, an...@green.mif.pg.gda.pl wrote:
Jeff Johnson wrote:
Another approach would be to not bother with static *.py* content
packaged in *.rpm at all, but rather let python establish its own
format/implementation for install/upgrade/erase of python code.
This
On Sun, Apr 3, 2011 at 3:04 PM, Jacek Konieczny jaj...@jajcus.net wrote:
On Sun, Apr 03, 2011 at 02:38:49PM +0200, Patryk Zawadzki wrote:
Except in Python you can execute/import .py files just fine. If the
program is not closed source, .pyc/.pyo/__pycache__ are just an
optimization detail. We
On Apr 3, 2011, at 9:15 AM, Patryk Zawadzki wrote:
On Sun, Apr 3, 2011 at 3:04 PM, Jacek Konieczny jaj...@jajcus.net wrote:
On Sun, Apr 03, 2011 at 02:38:49PM +0200, Patryk Zawadzki wrote:
Except in Python you can execute/import .py files just fine. If the
program is not closed source,
On Sun, Apr 3, 2011 at 3:27 PM, Jeff Johnson n3...@mac.com wrote:
I see a problem with /usr/bin/__pycache__/* and the rest of
the python litter on a file system. While __pycache__ subdirs works in
python's
module trees, there will be a litter of __pycache__ subdirs on other
paths.
But
On Apr 3, 2011, at 4:01 PM, Patryk Zawadzki wrote:
On Sun, Apr 3, 2011 at 3:27 PM, Jeff Johnson n3...@mac.com wrote:
I see a problem with /usr/bin/__pycache__/* and the rest of
the python litter on a file system. While __pycache__ subdirs works in
python's
module trees, there will be a
On Sun, Apr 03, 2011 at 10:01:32PM +0200, Patryk Zawadzki wrote:
On Sun, Apr 3, 2011 at 3:27 PM, Jeff Johnson n3...@mac.com wrote:
I see a problem with /usr/bin/__pycache__/* and the rest of
the python litter on a file system. While __pycache__ subdirs works in
python's
module trees,
It seems that since python 3.2 upstream changed the default way
of creating compiled files: instead of *.pyc/*.pyo in the same
directory that .py file exists, the compiled files are created
in __pycache__ subdirectory.
According to some googled information, the old method (files created
in the
On Saturday 02 of April 2011, Jakub Bogusz wrote:
So we have to decide how to package python distribution (and possibly
all python3 modules, if distutils use __pycache__ too) - there are
two solutions:
- package all modules in source form together with __pycache__
subdirectories
I would
On Sat, Apr 2, 2011 at 8:22 PM, Arkadiusz Miskiewicz ar...@maven.pl wrote:
On Saturday 02 of April 2011, Jakub Bogusz wrote:
So we have to decide how to package python distribution (and possibly
all python3 modules, if distutils use __pycache__ too) - there are
two solutions:
- package all
39 matches
Mail list logo
