Jason, I'm in agreement. I think it would be great if the primary way for users to install SCons was via pip (and virtualenv if they like, which I do).
I've been (as time allows) looking at the current setup logic and trying to understand it's purposes. I think it should be possible to provide most if not all of the use models for the different install packages via pip and possibly with a runnable zipp'd scons. (I think distutils supports this now?) I made an initial attempt but, aborted it because I ran into many issues and realized I needed a step back. The only big question in my mind is if we were to stop providing the -local package and install a runnable zip instead, would that cause a lot of trouble for users. -Bill On Tue, Mar 31, 2015 at 10:52 AM, Kenny, Jason L <jason.l.ke...@intel.com> wrote: > > > Hi guys, > > > > I been fixing up Parts packaging logic so it is pip and wheel friendly. I > was wonder what are the plans for SCons on this front? It seems to me that > this should not be that complex for us to do in SCons. I just noticed there > is a lot of work going on in the current scripts with coping data around. > Is all this needed for a reason. > > > > I guess the real question is that: > > > > Do we need to have SCons not install as a python package? > > > > Minus the standalone install case. What value are we getting from this? I > know for me this makes extending SCons harder as there is odd logic to find > the real “path” to import SCons. > > > > I would like to propose simplifying this to make a pip friendly install of > SCons. > > > > Any thoughts? > > Jason > > _______________________________________________ > 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