[Buildroot] [PATCH 1/2] scanpypi: new utility

[Yegor Yefremov]

On Wed, Jan 13, 2016 at 4:23 PM, Thomas Petazzoni
<thomas.petazzoni at free-electrons.com> wrote:
> Arnout, Yann,
>
> On Sun, 10 Jan 2016 16:36:50 +0100, Arnout Vandecappelle wrote:
>
>> > So, we currently have scancpan to create perl packages. You are adding
>> > scanpypi to create Python packages. There's also someone who submitted
>> > a script to generate a 'generic' package (i.e. not perl/python) [0].
>> > The scancpan is written in perl, yours and the generic one in Python.
>> >
>> > Besides Perl and Python, we also have nodejs which provides a similar
>> > "package-store" and for which it would become interesting to provide a
>> > helper script to generate packages [1].
>> >
>> > What I would love to see is that we have a single script to add
>> > packages. Something like:
>> >
>> >     $ ./support/script/add-package -t TYPE [OPTS] PKG [PKG...]
>> >
>> > with TYPE being one of the package types we currently have (generic,
>> > autotools... python, perl...) or an abstract type (nodejs...).
>> >
>> > Then, the cpan, pypi, nodejs... script would be just 'backends' that
>> > would provide classes called by the main script, like;
>> >
>> >     pkg = new PythonPkg("foo")
>> >     pkg.get_br_name()       returns the BR2_PACKAGE_ name
>> >     pkg.get_version()       returns the _VERSION string
>> >     pkg.get_source()        returns the _SOURCE string
>> >     pkg.get_site()          returns the _SITE string
>> >     pkg.get_method()        returns the _SITE_METHOD string
>> >     pkg.get_dependencies()  returns the _DEPENDENCIES list
>> >     ... and so on, you get the idea. ;-)
>>
>>  However, it is more natural for a CPAN-accessor to be written in perl. So I
>> guess the backend scripts should be really independent scripts that report the
>> package metadata in a specified format. Hm, you know what, let's use Config.in
>> and pkg.mk as the specification!
>>
>>  In short, I'm not so convinced that having everything written in the same
>> language is such an advantage.
>>
>>  But of course, if someone shows me the patches, I could change my mind.
>
> I also initially would have preferred to have the scancpan script
> written in Python. But 1/ it's not very practical to query CPAN from
> Python, and more importantly 2/ it's a bit weird to ask to a Perl
> fan who maintains the Perl stuff in Buildroot to write something like
> scancpan in Python.
>
> Bottom line, my opinion is that:
>
>  1/ We should keep scancpan in Perl
>
>  2/ We should keep scanpipy in Python, refine it and merge it.
>
>  3/ The script that generates just a generic package skeleton is a bit
>     useless IMO and is not very useful to merge.
>
> Both scancpan and canpipy are really internal tools, for Buildroot
> developers, so it's not super important if they don't look like /
> behave the same.

I gave scanpypi a try: http://patchwork.ozlabs.org/patch/567288/

So far it was working as expected. Thanks for the very useful tool.

Yegor