[Scons-dev] Packaging logic?

[Kenny, Jason L]

What do you mean by “a runnable zip”

My main thought is that we move to using the wheel format. Given that my current tasks I have been learning much more detail on this. What I am still not sure about is if with wheel we can support more than one version of SCons installed at a time. This may not be an issue as this could be easily done with the standard virtual environment package in python. Given we have that we can still provide user with an msi/rpm/dep/zip/tar.gz package format.


As a FYI .. it seem we want to think of this in terms of setuputils and pip. Python at level 2.7.8-9 and above have an ensurepip package to make sure you can easily install pip and use it if it is not there. The wheel format seems to be the replacement for egg and has a standard PEP behind it.

Jason


From: Scons-dev [mailto:scons-dev-bounces at scons.org] On Behalf Of Bill Deegan
Sent: Wednesday, April 1, 2015 10:22 AM
To: SCons developer list
Subject: Re: [Scons-dev] Packaging logic?

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.kenny at intel.com<mailto:jason.l.kenny at 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 at scons.org<mailto:Scons-dev at scons.org>
https://pairlist2.pair.net/mailman/listinfo/scons-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist2.pair.net/pipermail/scons-dev/attachments/20150401/bd3deb67/attachment-0001.html>