One of the most common mistakes a developer can make is never look or work outside their usual environment. By never looking outside their own little sandbox, they risk losing sight of which improvements happen outside of their world, which they could easily factor in. This is why I always look at what Fedora, Debian and Ubuntu do, for instance.
Given my involvement with Ruby packaging, one of the things I should try to avoid covering myself with is Ruby itself; unfortunately trying to look at Python packaging is not something I’d be keen on doing anytime soon, given the state of python.eclass
(please guys, rewrite it, sooner rather than later!). But at least tonight I spent some time looking at Perl modules’ ebuilds.
The main reason why I went to look for those is because an user (Grant) asked me to add Google’s AdWords library for Perl to the main tree, but Perl is something I wanted to look at for a while, since I wanted to set up RT for my customers and the new versions require a few more dependencies.
At any rate, looking at Perl ebuilds for me is not too unnatural: while the fact that there is a single Perl implementation makes it much easier on them to implement the phases, the rest of the set up is not too different from what we have in Ruby land.
What seems to be more common there is that they also set HOMEPAGE
by default if none is set, since it seems like a lot of modules only have an homepage as part of CPAN, which is only different in the Ruby world due to the fact that most of the projects are managed on GitHub, which makes that their default homepage.
Having finally to take a good look at the g-cpan
tool, I have to say that I think that all the trials for a g-gem
tool or similar are quite out of target: instead of creating a tool that creates and install ebuilds for the pre-packaged extensions, we should have coordinated with RubyGems upstream to provide a few more details — such as a way to explicit the license the extension is released under, which CPAN does and RubyGems doesn’t, you can also see Mandriva struggling with the same issue in the final questions on my FOSDEM talk — and at that point we could have just created a tool that prepared a skeleton for our own ebuilds, rather than something fully automated like it has been tried before.
Anyway, I really like the idea of trying to package something you’re not usually used to, makes it easy to find what is different and what is similar, in approaches.
You are the most noticeable Gentoo developer and I really appreciate any work you do. It’s usually an internal, very invisible but very important piece of Gentoo.
What do you dislike in python.eclass?That it uses its own system instead of a PYTHON_TARGETS like Ruby and PHP have?It’s a bit annoying, and it needs a special tool (python-updater) that would not seem useful otherwise.
don’t know what Diego dislike of the py.eclass, but here are mine:1) sizewc -l portage/eclass | sort -n[…] 1230 /g/portage/eclass/kernel-2.eclass 1476 /g/portage/eclass/mysql.eclass 1501 /g/portage/eclass/eutils.eclass 2048 /g/portage/eclass/toolchain.eclass 2836 /g/portage/eclass/java-utils-2.eclass 3168 /g/portage/eclass/python.eclass 58355 totalenot speaking of java-utils-2 which I don’t know at all. The other eclasses listed do things much more complex than what the py.eclass should do.2) it wrap _every_ python executable in a complex enough script that make difficult to find the real executable.3) those 3168 lines of code are unreadable
More or less what Francesco said. The eclass is _huge_ and its behaviour sways a lot depending on EAPI version; also there has been so many changes that made various overlays’ ebuilds incompatible at one point or another, and we _still_ get ebuilds that from time to time fail the _removal_ phase because the cleanup is not properly wired in.All in all, it’s a real mess. And most of the current developers seem to agree on that. The problem is that to rewrite it, it takes a lot of work, and not everybody is keen on doing so especially considering how complicated it is right now.
There does seem to be a new approach to python ebuilds in the “progress”:https://code.google.com/p/g… overlay.p.s The textile enabled link doesn’t seem to work. A quick google gave me http://www.textism.com/tool…