[Scons-users] SCons Tools maintenance

[Bill Deegan]

Luke,

That sounds very interesting!
Is the code in a public repo so we can take a look at it?

-Bill
SCons Project Co-Manager

On Thu, Nov 9, 2017 at 7:34 AM, Luke Tunmer <luke.tunmer at gmail.com> wrote:

> I have developed a regular Python package that when imported into an
> SConstuct file, looks for other SCons Python packages using the
> entry_points mechanism of setup tools. It then calls each of these entry
> points to get the Tools path that will allow tools to be found when they
> are added to an environment. This means that these extensions just have to
> be installed into the virtualenv from which the scons is running. This is
> done by having a requirements.txt file that lists all the SCons extensions
> tools needed for the product or component.
>
> Then we have an internal devpi server which allows these SCons extension
> packages to be found.
>
> I would like one day to see SCons directly support the idea of entry_point
> extensions, which seems to used increasingly as a means to introduce
> plugins into larger frameworks.
>
> Regards
> Luke
>
>
> On 9 November 2017 at 11:33, Nacho Piqueras <natxo.piq at gmail.com> wrote:
>
>> Hello all,
>>
>> Even if it is a not very much documented feature, I find SCons' Tools one
>> of the most powerful concepts to arrange a build that involves several code
>> transformations. In our projects we use a lot of 3rd party code generators
>> and we wrap them into SCons tools to bring their functionality to the build
>> environment.
>>
>> The problem we face is that tools packages are distributed per project.
>> Currently all SCons tools that are required for a specific project are
>> included into a site-tools folder inside that project. Being this way, we
>> have the source code distribution problem: sometimes the code for a tool
>> drifts from one project to another and it is difficult to track
>> bugs/improvements through projects.
>>
>> Because scons tools are really coupled with the tool they wrap we could
>> try to distribute the python package with the tool (the code generator),
>> but this is not always possible. Fresh install of a tool does not bring the
>> scons tool with it.
>>
>> Also, we would like to unit test the code of a tool. This involves
>> mocking a scons environment somehow... for at least testing that the action
>> would be correctly called, or the sequence of actions correctly arranged
>> (scons tools' code often define scanners, emitters...). I still have not
>> figured out how to do it.
>>
>> I would like to know how people using SCons distribute their SCons' tools
>> code, how do you deal with this situation.
>>
>> For example, maybe we could package scons tools and install them with pip
>> into a virtualenv created for a project...
>>
>> Many thanks for your thoughts on this question and for keeping SCons
>> evolving.
>>
>>
>> _______________________________________________
>> Scons-users mailing list
>> Scons-users at scons.org
>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>
>>
>
> _______________________________________________
> Scons-users mailing list
> Scons-users at scons.org
> https://pairlist4.pair.net/mailman/listinfo/scons-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20171109/ef50bc76/attachment-0001.html>