[gentoo-dev] GSoC 2020: Call for mentors and project ideas

[gentoo-dev] GSoC 2020: Call for mentors and project ideas

[alicef]

[-- Attachment #1.1.1: Type: text/plain, Size: 2710 bytes --]

Hello,


As always, Gentoo plans to participate in the Google Summer of Code
2020. We are looking for new project ideas and are always open for
new mentors.
Google Summer of Code is a big opportunity for making Gentoo project more
visible and get more people interested to join Gentoo and helping out.

1. Project ideas

GSoC projects should be suitable for 3 months worth of work for
a student, taking into account time required for students to get in
touch with the project, to learn some details, to fix mistakes and
make improvements. Most students are not yet seasoned developers,
so their coding rate will be likely slower than yours.

Usually projects are something more complicated than just writing
some ebuilds, however if non-trivial ebuild related work is
required, e.g. to write new eclasses and adapt existing packages to
use them (or add new ones), this should do too.

Ideas from previous years may be reused, but this should not be
abused, since Gentoo moves forward and we have new stuff to do.

If you have an idea, but can't be a mentor, please still tell us
about it, we'll try to find a mentor later.

Ideas should be put to our wiki: [1].
The page contains ideas adding howto.

2. Mentors

If you want to be a mentor, welcome! It is not necessary to be a
Gentoo developer in order to be a mentor, but project must be
Gentoo related.

Mentoring requires some time. It depends much on a student, but is
usually within 4-10 hours per week. If you don't have that much
time, but still want to help, you may become a backup mentor.
Students often have 2 mentors to eliminate bus factor and to
improve expertise in a project.

Please keep in mind that GSoC is not just about new code, but about
bringing new people to community and we have developers which where
GSoC students in the past. So time invested in students will result
not only in some problems solved, but into bringing new people to
our community and strengthening ties with existing participants.

Mentors should enlist themselves on the wiki: [2].

If you have any questions or proposals, feel free to reply to this
e-mail, or contact us via #gentoo-soc IRC channel on FreeNode[3],
or by writing to project's alias[4].



[1] https://wiki.gentoo.org/wiki/Google_Summer_of_Code/2020/Ideas
[2] https://wiki.gentoo.org/wiki/Google_Summer_of_Code/2020/Mentors
[3] http://webchat.freenode.net/?channels=gentoo-soc
[4] mailto:soc-mentors@gentoo.org


Thanks,
Alice


-- 
======================================
Thanks,
Alice Ferrazzi

Gentoo Kernel Project Leader
PGP: 2E4E 0856 461C 0585 1336 F496 5621 A6B2 8638 781A
====================================== 

[-- Attachment #1.1.2: 0x5621A6B28638781A.asc --]
[-- Type: application/pgp-keys, Size: 19695 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] GSoC 2020: Call for mentors and project ideas

[Benda Xu]

[-- Attachment #1: Type: text/plain, Size: 544 bytes --]

Thank you Alice!

alicef <alicef@gentoo.org> writes:

> As always, Gentoo plans to participate in the Google Summer of Code
> 2020. We are looking for new project ideas and are always open for
> new mentors.
> Google Summer of Code is a big opportunity for making Gentoo project more
> visible and get more people interested to join Gentoo and helping out.
>
> [...]

Gentoo has receive high quality contributions in the past.  I hope this
year we could have attract more talented Google Summer of Code students
to work with us.

Cheers,
Benda

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: [gentoo-dev] GSoC 2020: Call for mentors and project ideas

[Benda Xu]

[-- Attachment #1: Type: text/plain, Size: 620 bytes --]

Dear Fellows,

alicef <alicef@gentoo.org> writes:

> As always, Gentoo plans to participate in the Google Summer of Code
> 2020. We are looking for new project ideas and are always open for
> new mentors.
> Google Summer of Code is a big opportunity for making Gentoo project more
> visible and get more people interested to join Gentoo and helping out.
>
> [...]

This year's GSoC organization application deadline is on Feb 5.  The
more project ideas, the better Gentoo will show itself to be prepared.
If you have been thinking of adding projects to our GSoC 2020 list, this
is a good chance to do so.

Cheers,
Benda

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: [gentoo-dev] GSoC 2020: Call for mentors and project ideas

[Gerion Entrup]

[-- Attachment #1: Type: text/plain, Size: 2363 bytes --]

Am Sonntag, 2. Februar 2020, 12:47:55 CET schrieb Benda Xu:
> Dear Fellows,
> 
> alicef <alicef@gentoo.org> writes:
> 
> > As always, Gentoo plans to participate in the Google Summer of Code
> > 2020. We are looking for new project ideas and are always open for
> > new mentors.
> > Google Summer of Code is a big opportunity for making Gentoo project more
> > visible and get more people interested to join Gentoo and helping out.
> >
> > [...]
> 
> This year's GSoC organization application deadline is on Feb 5.  The
> more project ideas, the better Gentoo will show itself to be prepared.
> If you have been thinking of adding projects to our GSoC 2020 list, this
> is a good chance to do so.
> 
> Cheers,
> Benda
> 

Hi,

I saw the idea „Big Data Infrastructure by Gentoo“ and found it kind of
interesting. However, I have a little bit the fear that a full automation
won't be possible and the whole project becomes a little bit like g-sorcery
(gs-pypi, gs-elpa) or g-octave: a really cool project but not used at a
large scale.

What do you think of the idea to not do this fully automated but supervised
by a maintainer? With that I mean an ebuild generator that generates only
the parts of the ebuild that it can easily parse and then present the ebuild
draft to a maintainer who completes it to an full ebuild. As far a I know no
tool like this exists. I think the focus shift helps a lot:
Developing a tool for the Gentoo maintainer not the Gentoo user.

I'm only "maintaining" an overlay so maybe I'm  missing experience
but I often have wished a tool that automatically parses the language specific
packaging files and is able to generate a primitive ebuild out of that.
Maybe it even can do this in an interactive way:
"Hey, upstream needs the dependency 'foo'. In the Gentoo packages I have found
'dev-bar/foo' and 'dev-util/foo'. What is the correct one?"

With a not fully automatic tool also packages can be parsed that are not
in a complete closed ecosystem, like a 'meson.build' file or cmake files for
C++/C programs. But of course package databases like Maven/Cargo/Pypi are
also candidates.

Unfortunately, I have no time currently to participate in the GSOC. I just
want to mention this here as an idea. Please comment or correct me, if
such a tool already exists.

Best,
Gerion


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

[gentoo-dev] Ebuild Generators (Was: GSoC 2020: Call for mentors and project ideas)

[Benda Xu]

[-- Attachment #1: Type: text/plain, Size: 2381 bytes --]

Hi Gerion,

Gerion Entrup <gerion.entrup@flump.de> writes:

> I saw the idea „Big Data Infrastructure by Gentoo“ and found it kind of
> interesting. However, I have a little bit the fear that a full automation
> won't be possible and the whole project becomes a little bit like g-sorcery
> (gs-pypi, gs-elpa) or g-octave: a really cool project but not used at a
> large scale.

Yes, that's true.  I share the same observation and concern with you.

This is one exception: the CRAN ebuild generator powered R overlay has
been running well for 8 years.

  https://wiki.gentoo.org/wiki/Project:Science/Overlay/R

> What do you think of the idea to not do this fully automated but supervised
> by a maintainer? With that I mean an ebuild generator that generates only
> the parts of the ebuild that it can easily parse and then present the ebuild
> draft to a maintainer who completes it to an full ebuild. As far a I know no
> tool like this exists. I think the focus shift helps a lot:
> Developing a tool for the Gentoo maintainer not the Gentoo user.

Yes, that makes a lot of sense.  The R overlay follows this model.  Most
of the ebuilds are automated.  When an ebuild generation fails, we add
the ebuild manually, understand it and then update the generator to
cover it in the future.

> I'm only "maintaining" an overlay so maybe I'm  missing experience
> but I often have wished a tool that automatically parses the language specific
> packaging files and is able to generate a primitive ebuild out of that.
> Maybe it even can do this in an interactive way:
> "Hey, upstream needs the dependency 'foo'. In the Gentoo packages I have found
> 'dev-bar/foo' and 'dev-util/foo'. What is the correct one?"

Yes, that's the way R overlay is working.  And I have a similar plan and
proof-of-concept solution for the Java Maven overlay.

> With a not fully automatic tool also packages can be parsed that are not
> in a complete closed ecosystem, like a 'meson.build' file or cmake files for
> C++/C programs. But of course package databases like Maven/Cargo/Pypi are
> also candidates.
>
> Unfortunately, I have no time currently to participate in the GSOC. I just
> want to mention this here as an idea. Please comment or correct me, if
> such a tool already exists.

Thank you!  Your input is really valuable.

Yours,
Benda

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: [gentoo-dev] Ebuild Generators (Was: GSoC 2020: Call for mentors and project ideas)

[Gerion Entrup]

[-- Attachment #1: Type: text/plain, Size: 2373 bytes --]

Am Montag, 3. Februar 2020, 05:20:42 CET schrieb Benda Xu:
> Gerion Entrup <gerion.entrup@flump.de> writes:
> 
> > I saw the idea „Big Data Infrastructure by Gentoo“ and found it kind of
> > interesting. However, I have a little bit the fear that a full automation
> > won't be possible and the whole project becomes a little bit like g-sorcery
> > (gs-pypi, gs-elpa) or g-octave: a really cool project but not used at a
> > large scale.
> 
> Yes, that's true.  I share the same observation and concern with you.
> 
> This is one exception: the CRAN ebuild generator powered R overlay has
> been running well for 8 years.
> 
>   https://wiki.gentoo.org/wiki/Project:Science/Overlay/R
Hmm, interesting, thank you.


> > What do you think of the idea to not do this fully automated but supervised
> > by a maintainer? With that I mean an ebuild generator that generates only
> > the parts of the ebuild that it can easily parse and then present the ebuild
> > draft to a maintainer who completes it to an full ebuild. As far a I know no
> > tool like this exists. I think the focus shift helps a lot:
> > Developing a tool for the Gentoo maintainer not the Gentoo user.
> 
> Yes, that makes a lot of sense.  The R overlay follows this model.  Most
> of the ebuilds are automated.  When an ebuild generation fails, we add
> the ebuild manually, understand it and then update the generator to
> cover it in the future.
Is this possible in all cases? I think of adding custom patches,
appropriate mapping of dependencies, check for things like desktop icon
cache...


> > I'm only "maintaining" an overlay so maybe I'm  missing experience
> > but I often have wished a tool that automatically parses the language specific
> > packaging files and is able to generate a primitive ebuild out of that.
> > Maybe it even can do this in an interactive way:
> > "Hey, upstream needs the dependency 'foo'. In the Gentoo packages I have found
> > 'dev-bar/foo' and 'dev-util/foo'. What is the correct one?"
> 
> Yes, that's the way R overlay is working.  And I have a similar plan and
> proof-of-concept solution for the Java Maven overlay.
Nice to hear. I think, it is meaningful to solve all generation with one
tool. Maybe it can even "recognize" the used build system and package
database. Is this your plan, too?


Best,
Gerion

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [gentoo-dev] Ebuild Generators

[Benda Xu]

[-- Attachment #1: Type: text/plain, Size: 1584 bytes --]

Hi Gerion,

Gerion Entrup <gerion.entrup@flump.de> writes:

>> Yes, that makes a lot of sense.  The R overlay follows this model.  Most
>> of the ebuilds are automated.  When an ebuild generation fails, we add
>> the ebuild manually, understand it and then update the generator to
>> cover it in the future.
>
> Is this possible in all cases? I think of adding custom patches,
> appropriate mapping of dependencies, check for things like desktop
> icon cache...

That's too complex to handle automatically.  Luckily, in R overlay, such
packages are less than 5%.  An ebuild generator is based on the
observation that many language-specific packages are trivial to fetch,
compile and install.

>> > I'm only "maintaining" an overlay so maybe I'm  missing experience
>> > but I often have wished a tool that automatically parses the language specific
>> > packaging files and is able to generate a primitive ebuild out of that.
>> > Maybe it even can do this in an interactive way:
>> > "Hey, upstream needs the dependency 'foo'. In the Gentoo packages I have found
>> > 'dev-bar/foo' and 'dev-util/foo'. What is the correct one?"
>> 
>> Yes, that's the way R overlay is working.  And I have a similar plan and
>> proof-of-concept solution for the Java Maven overlay.
>
> Nice to hear. I think, it is meaningful to solve all generation with one
> tool. Maybe it can even "recognize" the used build system and package
> database. Is this your plan, too?

No, I don't think it possible as far as I can see...  That would be a
strong AI.

Yours,
Benda

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: [gentoo-dev] Ebuild Generators

[Michael 'veremitz' Everitt]

[-- Attachment #1.1: Type: text/plain, Size: 1768 bytes --]

On 03/02/20 12:19, Benda Xu wrote:
> Hi Gerion,
>
> Gerion Entrup <gerion.entrup@flump.de> writes:
>
>>> Yes, that makes a lot of sense.  The R overlay follows this model.  Most
>>> of the ebuilds are automated.  When an ebuild generation fails, we add
>>> the ebuild manually, understand it and then update the generator to
>>> cover it in the future.
>> Is this possible in all cases? I think of adding custom patches,
>> appropriate mapping of dependencies, check for things like desktop
>> icon cache...
> That's too complex to handle automatically.  Luckily, in R overlay, such
> packages are less than 5%.  An ebuild generator is based on the
> observation that many language-specific packages are trivial to fetch,
> compile and install.
>
>>>> I'm only "maintaining" an overlay so maybe I'm  missing experience
>>>> but I often have wished a tool that automatically parses the language specific
>>>> packaging files and is able to generate a primitive ebuild out of that.
>>>> Maybe it even can do this in an interactive way:
>>>> "Hey, upstream needs the dependency 'foo'. In the Gentoo packages I have found
>>>> 'dev-bar/foo' and 'dev-util/foo'. What is the correct one?"
>>> Yes, that's the way R overlay is working.  And I have a similar plan and
>>> proof-of-concept solution for the Java Maven overlay.
>> Nice to hear. I think, it is meaningful to solve all generation with one
>> tool. Maybe it can even "recognize" the used build system and package
>> database. Is this your plan, too?
> No, I don't think it possible as far as I can see...  That would be a
> strong AI.
>
> Yours,
> Benda
There was some interest in doing this for PyPI packages for Liguros linux.
See https://gitlab.com/liguros/bugs/issues/75 .


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [gentoo-dev] Ebuild Generators

[Gerion Entrup]

[-- Attachment #1: Type: text/plain, Size: 1958 bytes --]

Am Montag, 3. Februar 2020, 13:19:52 CET schrieb Benda Xu:
> Hi Gerion,
> 
> Gerion Entrup <gerion.entrup@flump.de> writes:
> 
> >> Yes, that makes a lot of sense.  The R overlay follows this model.  Most
> >> of the ebuilds are automated.  When an ebuild generation fails, we add
> >> the ebuild manually, understand it and then update the generator to
> >> cover it in the future.
> >
> > Is this possible in all cases? I think of adding custom patches,
> > appropriate mapping of dependencies, check for things like desktop
> > icon cache...
> 
> That's too complex to handle automatically.  Luckily, in R overlay, such
> packages are less than 5%.  An ebuild generator is based on the
> observation that many language-specific packages are trivial to fetch,
> compile and install.
> 
> >> > I'm only "maintaining" an overlay so maybe I'm  missing experience
> >> > but I often have wished a tool that automatically parses the language specific
> >> > packaging files and is able to generate a primitive ebuild out of that.
> >> > Maybe it even can do this in an interactive way:
> >> > "Hey, upstream needs the dependency 'foo'. In the Gentoo packages I have found
> >> > 'dev-bar/foo' and 'dev-util/foo'. What is the correct one?"
> >> 
> >> Yes, that's the way R overlay is working.  And I have a similar plan and
> >> proof-of-concept solution for the Java Maven overlay.
> >
> > Nice to hear. I think, it is meaningful to solve all generation with one
> > tool. Maybe it can even "recognize" the used build system and package
> > database. Is this your plan, too?
> 
> No, I don't think it possible as far as I can see...  That would be a
> strong AI.
I mean only on a primitive base:
```
if link contains "pypi":
    # it's a Python package from pypi
    handle_pypi()
elif work_tree contains "setup.py":
    # it's a Python package
    handle_generic_python()
elif work_tree contains "meson.build":
    handle_meson_package()
...
```

Best,
Gerion

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [gentoo-dev] Ebuild Generators

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 2630 bytes --]

On Mon, 2020-02-03 at 14:20 +0100, Gerion Entrup wrote:
> Am Montag, 3. Februar 2020, 13:19:52 CET schrieb Benda Xu:
> > Hi Gerion,
> > 
> > Gerion Entrup <gerion.entrup@flump.de> writes:
> > 
> > > > Yes, that makes a lot of sense.  The R overlay follows this model.  Most
> > > > of the ebuilds are automated.  When an ebuild generation fails, we add
> > > > the ebuild manually, understand it and then update the generator to
> > > > cover it in the future.
> > > 
> > > Is this possible in all cases? I think of adding custom patches,
> > > appropriate mapping of dependencies, check for things like desktop
> > > icon cache...
> > 
> > That's too complex to handle automatically.  Luckily, in R overlay, such
> > packages are less than 5%.  An ebuild generator is based on the
> > observation that many language-specific packages are trivial to fetch,
> > compile and install.
> > 
> > > > > I'm only "maintaining" an overlay so maybe I'm  missing experience
> > > > > but I often have wished a tool that automatically parses the language specific
> > > > > packaging files and is able to generate a primitive ebuild out of that.
> > > > > Maybe it even can do this in an interactive way:
> > > > > "Hey, upstream needs the dependency 'foo'. In the Gentoo packages I have found
> > > > > 'dev-bar/foo' and 'dev-util/foo'. What is the correct one?"
> > > > 
> > > > Yes, that's the way R overlay is working.  And I have a similar plan and
> > > > proof-of-concept solution for the Java Maven overlay.
> > > 
> > > Nice to hear. I think, it is meaningful to solve all generation with one
> > > tool. Maybe it can even "recognize" the used build system and package
> > > database. Is this your plan, too?
> > 
> > No, I don't think it possible as far as I can see...  That would be a
> > strong AI.
> I mean only on a primitive base:
> ```
> if link contains "pypi":
>     # it's a Python package from pypi
>     handle_pypi()
> elif work_tree contains "setup.py":
>     # it's a Python package
>     handle_generic_python()
> 

Please don't use generators for Python.  You'd have to put a lot of
effort to get things right.  Most of the time, you'll end up with broken
or no tests, useless deps and py2 where unnecessary.

Creating ebuilds is not a problem.  Maintaining is.  Python team ended
up with lots of packages dumped by former project members or other
developers.  Many of them are of very bad quality.  Even those that
aren't are a maintenance burden.  Removing broken and/or useless
packages is taking a lot of our time.

-- 
Best regards,
Michał Górny


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

Re: [gentoo-dev] Ebuild Generators

[Tom Gillespie]

For historical curiosity there was also
https://github.com/domenkozar/g-pypi at one point (similar to
https://github.com/rafaelmartins/g-octave). Having used g-octave, the
primary issue is as Michał says, there are a lot of corner cases that
the generation doesn't handle correctly which lead to broken ebuilds
and maintenance headaches. Speaking for python, catching and
correcting the use of setup_requires and other insanity visited upon
us by the wonders of setuptools makes this a non-starter. If you have
a set a known sane packages you could in theory write an eclass that
captures the regularities of those packages, but I'm not sure eclasses
are suggested for that use case.
Tom

On Mon, Feb 3, 2020 at 5:27 AM Michał Górny <mgorny@gentoo.org> wrote:
>
> On Mon, 2020-02-03 at 14:20 +0100, Gerion Entrup wrote:
> > Am Montag, 3. Februar 2020, 13:19:52 CET schrieb Benda Xu:
> > > Hi Gerion,
> > >
> > > Gerion Entrup <gerion.entrup@flump.de> writes:
> > >
> > > > > Yes, that makes a lot of sense.  The R overlay follows this model.  Most
> > > > > of the ebuilds are automated.  When an ebuild generation fails, we add
> > > > > the ebuild manually, understand it and then update the generator to
> > > > > cover it in the future.
> > > >
> > > > Is this possible in all cases? I think of adding custom patches,
> > > > appropriate mapping of dependencies, check for things like desktop
> > > > icon cache...
> > >
> > > That's too complex to handle automatically.  Luckily, in R overlay, such
> > > packages are less than 5%.  An ebuild generator is based on the
> > > observation that many language-specific packages are trivial to fetch,
> > > compile and install.
> > >
> > > > > > I'm only "maintaining" an overlay so maybe I'm  missing experience
> > > > > > but I often have wished a tool that automatically parses the language specific
> > > > > > packaging files and is able to generate a primitive ebuild out of that.
> > > > > > Maybe it even can do this in an interactive way:
> > > > > > "Hey, upstream needs the dependency 'foo'. In the Gentoo packages I have found
> > > > > > 'dev-bar/foo' and 'dev-util/foo'. What is the correct one?"
> > > > >
> > > > > Yes, that's the way R overlay is working.  And I have a similar plan and
> > > > > proof-of-concept solution for the Java Maven overlay.
> > > >
> > > > Nice to hear. I think, it is meaningful to solve all generation with one
> > > > tool. Maybe it can even "recognize" the used build system and package
> > > > database. Is this your plan, too?
> > >
> > > No, I don't think it possible as far as I can see...  That would be a
> > > strong AI.
> > I mean only on a primitive base:
> > ```
> > if link contains "pypi":
> >     # it's a Python package from pypi
> >     handle_pypi()
> > elif work_tree contains "setup.py":
> >     # it's a Python package
> >     handle_generic_python()
> >
>
> Please don't use generators for Python.  You'd have to put a lot of
> effort to get things right.  Most of the time, you'll end up with broken
> or no tests, useless deps and py2 where unnecessary.
>
> Creating ebuilds is not a problem.  Maintaining is.  Python team ended
> up with lots of packages dumped by former project members or other
> developers.  Many of them are of very bad quality.  Even those that
> aren't are a maintenance burden.  Removing broken and/or useless
> packages is taking a lot of our time.
>
> --
> Best regards,
> Michał Górny
>

Re: [gentoo-dev] Ebuild Generators

[Benda Xu]

Tom Gillespie <tgbugs@gmail.com> writes:

> For historical curiosity there was also
> https://github.com/domenkozar/g-pypi at one point (similar to
> https://github.com/rafaelmartins/g-octave). Having used g-octave, the
> primary issue is as Michał says, there are a lot of corner cases that
> the generation doesn't handle correctly which lead to broken ebuilds
> and maintenance headaches. Speaking for python, catching and
> correcting the use of setup_requires and other insanity visited upon
> us by the wonders of setuptools makes this a non-starter. 

Yes, I agree.

> If you have a set a known sane packages you could in theory write an
> eclass that captures the regularities of those packages, but I'm not
> sure eclasses are suggested for that use case.

eclass is designed for eliminating duplicated code in ebuilds. Therefore
yes, it is the legitimate use of eclass.

Benda

Re: [gentoo-dev] Ebuild Generators

[Gerion Entrup]

[-- Attachment #1: Type: text/plain, Size: 1012 bytes --]

Am Dienstag, 11. Februar 2020, 16:18:44 CET schrieb Tom Gillespie:
> For historical curiosity there was also
> https://github.com/domenkozar/g-pypi at one point (similar to
> https://github.com/rafaelmartins/g-octave). Having used g-octave, the
> primary issue is as Michał says, there are a lot of corner cases that
> the generation doesn't handle correctly which lead to broken ebuilds
> and maintenance headaches. Speaking for python, catching and
> correcting the use of setup_requires and other insanity visited upon
> us by the wonders of setuptools makes this a non-starter
That's essentially my whole point. Generators are _not_ able to catch all
corner cases but should be able to lower the initial ebuild creation
cost. That could be such things like figure out the license, try to
fill the source url, ....
In principal: Try to automate what is possible and leave the rest to
the maintainer.

But in that state they are a tool for the Gentoo developer not for the
user.

Gerion


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 659 bytes --]