A thought. If using the six module will be part of our 2.7/3.x port, then rather than copying all that into our tree (which I would say was a reasonable solution back when SCons started and pypi wasn't available or mature), perhaps it's time to move to a virtualenv based development/distro flow.
You can see what they do in Buildbot here: http://trac.buildbot.net/wiki/RunningBuildbotWithVirtualEnv Not that I'm advising adding dependencies willy/nilly (Oh man am I the old guy now), but reasonable dependency additions then become easily manageable. Thoughts? -Bill On Fri, Oct 23, 2015 at 9:47 AM, Gary Oberbrunner <ga...@oberbrunner.com> wrote: > Python mocks are extremely useful. We use them in my day job and > unit-testing that code would be pretty hard without them. The main > counterargument to using them in SCons is that it introduces a dependency, > and to date SCons can build and test with no external dependencies. But of > course that's not _really_ true: many SCons tests test compilers and tools > that are often not present, so those tests get skipped.That's one route you > could take: if no mock module exists, skip the tests. But another way this > has been done in SCons in the past is to copy the module into SCons, e.g. > in the src/engine/SCons/compat subdir, with appropriate name changes. If > the module in question's license permits this, and it's self-contained, why > not do this? In this case it'd probably want to be under QMTest but the > principle is the same. > > Quoting from src/engine/SCons/compat/__init__.py: > > *This subpackage holds modules that provide backwards-compatible* > *implementations of various things that we'd like to use in SCons but > which* > *only show up in later versions of Python than the early, old version(s)* > *we still support.* > > > Other devs, what do you think? > > On Fri, Oct 23, 2015 at 12:27 PM, Paweł Tomulik <ptomu...@meil.pw.edu.pl> > wrote: > >> This is the module I'm currently working on: >> >> https://github.com/ptomulik/scons-arguments >> >> for the moment 'devel' branch is more recent: >> >> https://github.com/ptomulik/scons-arguments/tree/devel >> >> Mocks are used in unit tests: >> >> >> https://github.com/ptomulik/scons-arguments/blob/master/unit_tests/SConsArgumentsTests.py >> >> It's hard to tell what's the particular purpose of using mocks for a >> particular project. It's rather a choice of testing philosophy. Mocks >> always play same role: to isolate the behaviour of the object (or >> method) being tested on other objects (or methods). That way less tests >> get affected when a particular object changes its behaviour. >> >> >> W dniu 23.10.2015 o 16:19, Bill Deegan pisze: >> > Pawel, >> > >> > If the plan was to migrate SCons to 3.x and drop support for 2.7, then >> > maybe using mocks would be ok now. >> > But the plan is to support both for some time once we get SCons working >> > with 3.x. >> > >> > What are you using mocks for now? Can you point to a repo? >> > Note that thus far, the mocks module has not been used, so chances are >> > it can be done without additional modules (though perhaps with more >> code). >> > >> > -Bill >> > >> > On Fri, Oct 23, 2015 at 1:56 AM, Paweł Tomulik <ptomu...@meil.pw.edu.pl >> > <mailto:ptomu...@meil.pw.edu.pl>> wrote: >> > >> > So, what should I replace my existing mocks with? Do you know any >> > technique? >> > >> > These mocks would only be required for unit-testing scons package, >> so >> > this doesn't affect plain users (only developers and scons package >> > maintainers would be affected). And starting from 3.3, the mock >> module >> > is part of python standard. >> > >> > >> > >> > W dniu 23.10.2015 o 09:21, Alexandre Feblot pisze: >> > > Hi, >> > > Please, please, please, >> > > Don't! >> > > Don't force people to install additional modules. >> > > One of Python benefits is how rich its standard distribution is, >> > compared to perl for example, allowing to distribute code that you >> > know will work everywhere without additional requirement. >> > > Please don't break that. >> > > >> > > Alexandre >> > > >> > >> Le 22 oct. 2015 à 23:58, Pawel Tomulik <ptomu...@meil.pw.edu.pl >> > <mailto:ptomu...@meil.pw.edu.pl>> a écrit : >> > >> >> > >> Hi, >> > >> >> > >> If I would like to contribute a module to scons, would it be >> > acceptable >> > >> to use mocks (https://pypi.python.org/pypi/mock) in unit tests? >> From >> > >> what I see, none of the existsing unit tests in SCons use mocks, >> > perhaps >> > >> for a reason? Is it forbidden? Is there an alternative without >> > using the >> > >> module? >> > >> >> > >> The mock module is not included in the basic python distribution, >> > it has >> > >> to be installed, for example with pip (it's a backport of >> > unittest.mock >> > >> available in python >=3.3). >> > >> >> > >> >> > >> Best regards! >> > >> >> > >> -- >> > >> Paweł Tomulik >> > >> >> > >> _______________________________________________ >> > >> Scons-dev mailing list >> > >> Scons-dev@scons.org <mailto:Scons-dev@scons.org> >> > >> https://pairlist2.pair.net/mailman/listinfo/scons-dev >> > > _______________________________________________ >> > > Scons-dev mailing list >> > > Scons-dev@scons.org <mailto:Scons-dev@scons.org> >> > > https://pairlist2.pair.net/mailman/listinfo/scons-dev >> > > >> > >> > >> > -- >> > Paweł Tomulik, tel. (22) 234 7925 >> > Instytut Techniki Lotniczej i Mechaniki Stosowanej >> > Politechnika Warszawska >> > _______________________________________________ >> > Scons-dev mailing list >> > Scons-dev@scons.org <mailto:Scons-dev@scons.org> >> > https://pairlist2.pair.net/mailman/listinfo/scons-dev >> > >> > >> > >> > >> > _______________________________________________ >> > Scons-dev mailing list >> > Scons-dev@scons.org >> > https://pairlist2.pair.net/mailman/listinfo/scons-dev >> > >> >> >> -- >> Pawel Tomulik >> _______________________________________________ >> Scons-dev mailing list >> Scons-dev@scons.org >> https://pairlist2.pair.net/mailman/listinfo/scons-dev >> > > > > -- > Gary > > _______________________________________________ > Scons-dev mailing list > Scons-dev@scons.org > https://pairlist2.pair.net/mailman/listinfo/scons-dev > >
_______________________________________________ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev