On Fri, Mar 25, 2016 at 8:43 PM, Bill Deegan <b...@baddogconsulting.com> wrote: > One question for the user base would be if anyone uses this ability anymore? > If not, good let's drop it. > > I'm all for moving to a pip based install as the primary method, with > scons-local still supported. > Though perhaps single file scons-local would be useful and/or better? > > Thoughts?
First, the status quo needs to be documented - blog post or something. It took me few years to figure SCons installation scenarios, and I am still not 100% sure that I get everything right, especially on Linux/OS X. I would drop hacks to install multiple versions of SCons into single Python environment in favor of using multiple environments. Then I would also consider refactoring SCons-local to SCons portable making current codebase portable by default, so that you can run SCons as a Python package. Speaking of portability, I'd also experiment with modular SCons structure - make a version that consists of core with all tools stripped and an ability to quickly add/discover/embed modules to that. So that people can construct their maintainable set and checkin it to their repository. So, goals: 1. one SCons per Python 2. easy override with own importable SCons (own SCons committed to repository) 3. describe SCons installation scenarios 4. refactor SCons-local to copy of repository source 5. experiment with modular structure P.S. I am getting back to it from https://github.com/GodotBuilder/godot-builds/pull/2 _______________________________________________ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev