Re: [Scons-dev] Packaging logic?
pip install . would install the current setup.py in the directory ( and I should add allow you to then do a “pip uninstall scons” to remove it. You can still do a “python setup.py install” as well you however would now have meta generated to remove it with a nice command. Not ok. SCons is a build system, so it should build itself to experiment on a live code. If we can teach pip to invoke scons as a part of build step - that is ok. I'd say that there is a even a demand for a cross-platform build tool that can work with pip to build binary stuff like extensions. Not sure what is not OK. If you have python setup.py install Scons installs… but how do you remove it… you don’t Pip install SCons Installs it like the above. But now I want to remove it: Pip uninstall SCons. That is nice… what is wrong with that? Jason From: Scons-dev [mailto:scons-dev-boun...@scons.org] On Behalf Of anatoly techtonik Sent: Tuesday, April 7, 2015 11:23 AM To: SCons developer list Subject: Re: [Scons-dev] Packaging logic? On Fri, Apr 3, 2015 at 7:28 PM, Kenny, Jason L jason.l.ke...@intel.commailto:jason.l.ke...@intel.com wrote: The current way is to get a source dist and install it. This would not stop. You would be able to do the same thing. If nothing else will be broken then I don't mind against uploading wheels to PyPI. The difference in the below would be: Pip install scons would be default go to the internet and get SCons Ok. pip install . would install the current setup.py in the directory ( and I should add allow you to then do a “pip uninstall scons” to remove it. You can still do a “python setup.py install” as well you however would now have meta generated to remove it with a nice command. Not ok. SCons is a build system, so it should build itself to experiment on a live code. If we can teach pip to invoke scons as a part of build step - that is ok. I'd say that there is a even a demand for a cross-platform build tool that can work with pip to build binary stuff like extensions. -- anatoly t. ___ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
Re: [Scons-dev] Packaging logic?
On Thu, Apr 2, 2015 at 11:33 PM, Bill Deegan b...@baddogconsulting.com wrote: Anatoly, On non-windows platforms the current recommendation is download the .tgz, unpack, python setup.py it. That is certainly more complicated than: pip install scons. `sudo pip install scons` FWIW, and the recommendation is currently `sudo apt-get install scons` for Ubuntu and Debian `sudo yum install scons` for Fedora and I believe some ports magic for FreeBSD. For project larger with sources larger than 100Mb my recommendation is just to stuff scons into project sources. ___ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
Re: [Scons-dev] Packaging logic?
The current way is to get a source dist and install it. This would not stop. You would be able to do the same thing. The difference in the below would be: Pip install scons would be default go to the internet and get SCons pip install . would install the current setup.py in the directory ( and I should add allow you to then do a “pip uninstall scons” to remove it. You can still do a “python setup.py install” as well you however would now have meta generated to remove it with a nice command. Honestly the current model would work as is, making it work with pip just means we have more functional options to provide. Jason From: Scons-dev [mailto:scons-dev-boun...@scons.org] On Behalf Of Alexandre Feblot Sent: Friday, April 3, 2015 4:45 AM To: SCons developer list Subject: Re: [Scons-dev] Packaging logic? Hi, On environments where there is no internet access (banks, army, ...), or if scons needs to be internally patched before being installed, the current way is much easier than using pip, I guess. -- Alexandre Le 2 avr. 2015 à 22:33, Bill Deegan b...@baddogconsulting.commailto:b...@baddogconsulting.com a écrit : Anatoly, On non-windows platforms the current recommendation is download the .tgz, unpack, python setup.py it. That is certainly more complicated than: pip install scons. -Bill On Thu, Apr 2, 2015 at 5:43 AM, anatoly techtonik techto...@gmail.commailto:techto...@gmail.com wrote: On Wed, Apr 1, 2015 at 6:22 PM, Bill Deegan b...@baddogconsulting.commailto:b...@baddogconsulting.com wrote: 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). This is a can of worms IMO. SCons is not tool for Python programmers, so if you do that, you will require people to learn about Python packaging, which is an unnecessary hell. If the tools is needed by Python programmers, then plz. state how exactly. Put the real world need first - what are you trying to achieve with that, excluding the consistency with Python world? The primary function and the way of using SCons for me (and my vision for everybody else) is to be a build tool that can be put into source repository, so that you can directly build after checkout without messing with apt-get/yum/pip install ... and friends. ___ Scons-dev mailing list Scons-dev@scons.orgmailto:Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev ___ Scons-dev mailing list Scons-dev@scons.orgmailto: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
Re: [Scons-dev] Packaging logic?
Oh, ok. Thanks for the explanation. Forget my previous comment, then :-) -- Alexandre Le 3 avr. 2015 à 18:28, Kenny, Jason L jason.l.ke...@intel.com a écrit : The current way is to get a source dist and install it. This would not stop. You would be able to do the same thing. The difference in the below would be: Pip install scons would be default go to the internet and get SCons pip install . would install the current setup.py in the directory ( and I should add allow you to then do a “pip uninstall scons” to remove it. You can still do a “python setup.py install” as well you however would now have meta generated to remove it with a nice command. Honestly the current model would work as is, making it work with pip just means we have more functional options to provide. Jason From: Scons-dev [mailto:scons-dev-boun...@scons.org] On Behalf Of Alexandre Feblot Sent: Friday, April 3, 2015 4:45 AM To: SCons developer list Subject: Re: [Scons-dev] Packaging logic? Hi, On environments where there is no internet access (banks, army, ...), or if scons needs to be internally patched before being installed, the current way is much easier than using pip, I guess. -- Alexandre Le 2 avr. 2015 à 22:33, Bill Deegan b...@baddogconsulting.com a écrit : Anatoly, On non-windows platforms the current recommendation is download the .tgz, unpack, python setup.py it. That is certainly more complicated than: pip install scons. -Bill On Thu, Apr 2, 2015 at 5:43 AM, anatoly techtonik techto...@gmail.com wrote: On Wed, Apr 1, 2015 at 6:22 PM, Bill Deegan b...@baddogconsulting.com wrote: 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). This is a can of worms IMO. SCons is not tool for Python programmers, so if you do that, you will require people to learn about Python packaging, which is an unnecessary hell. If the tools is needed by Python programmers, then plz. state how exactly. Put the real world need first - what are you trying to achieve with that, excluding the consistency with Python world? The primary function and the way of using SCons for me (and my vision for everybody else) is to be a build tool that can be put into source repository, so that you can directly build after checkout without messing with apt-get/yum/pip install ... and friends. ___ 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 ___ 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
Re: [Scons-dev] Packaging logic?
As long as RPM distributions are still available, pip sounds like a win. On Apr 3, 2015 12:32 PM, Alexandre Feblot alexandre.feb...@gmail.com wrote: Oh, ok. Thanks for the explanation. Forget my previous comment, then :-) -- Alexandre Le 3 avr. 2015 à 18:28, Kenny, Jason L jason.l.ke...@intel.com a écrit : The current way is to get a source dist and install it. This would not stop. You would be able to do the same thing. The difference in the below would be: Pip install scons would be default go to the internet and get SCons pip install . would install the current setup.py in the directory ( and I should add allow you to then do a “pip uninstall scons” to remove it. You can still do a “python setup.py install” as well you however would now have meta generated to remove it with a nice command. Honestly the current model would work as is, making it work with pip just means we have more functional options to provide. Jason *From:* Scons-dev [mailto:scons-dev-boun...@scons.org scons-dev-boun...@scons.org] *On Behalf Of *Alexandre Feblot *Sent:* Friday, April 3, 2015 4:45 AM *To:* SCons developer list *Subject:* Re: [Scons-dev] Packaging logic? Hi, On environments where there is no internet access (banks, army, ...), or if scons needs to be internally patched before being installed, the current way is much easier than using pip, I guess. -- Alexandre Le 2 avr. 2015 à 22:33, Bill Deegan b...@baddogconsulting.com a écrit : Anatoly, On non-windows platforms the current recommendation is download the .tgz, unpack, python setup.py it. That is certainly more complicated than: pip install scons. -Bill On Thu, Apr 2, 2015 at 5:43 AM, anatoly techtonik techto...@gmail.com wrote: On Wed, Apr 1, 2015 at 6:22 PM, Bill Deegan b...@baddogconsulting.com wrote: 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). This is a can of worms IMO. SCons is not tool for Python programmers, so if you do that, you will require people to learn about Python packaging, which is an unnecessary hell. If the tools is needed by Python programmers, then plz. state how exactly. Put the real world need first - what are you trying to achieve with that, excluding the consistency with Python world? The primary function and the way of using SCons for me (and my vision for everybody else) is to be a build tool that can be put into source repository, so that you can directly build after checkout without messing with apt-get/yum/pip install ... and friends. ___ 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 ___ 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 ___ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
Re: [Scons-dev] Packaging logic?
Anatoly, On non-windows platforms the current recommendation is download the .tgz, unpack, python setup.py it. That is certainly more complicated than: pip install scons. -Bill On Thu, Apr 2, 2015 at 5:43 AM, anatoly techtonik techto...@gmail.com wrote: On Wed, Apr 1, 2015 at 6:22 PM, Bill Deegan b...@baddogconsulting.com wrote: 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). This is a can of worms IMO. SCons is not tool for Python programmers, so if you do that, you will require people to learn about Python packaging, which is an unnecessary hell. If the tools is needed by Python programmers, then plz. state how exactly. Put the real world need first - what are you trying to achieve with that, excluding the consistency with Python world? The primary function and the way of using SCons for me (and my vision for everybody else) is to be a build tool that can be put into source repository, so that you can directly build after checkout without messing with apt-get/yum/pip install ... and friends. ___ 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
Re: [Scons-dev] Packaging logic?
Real quick. I don’t there is a suggestion on not supporting standalone drops, etc.. I still would like to provide a msi on windows. There is a difference between a sdidt like drop vs a full standalone (py2exe like) drop however. Different systems view this differently. In general on linux and mac you have python as an easy package, windows it is a separate install ( still easy). Having a full standalone drop for mac, linux, windows mean that it easier for SCons to raise the base python version as we can provide a python 3.5 for example as part of the install. However I have found this idea is easy on windows, hard on linux. Jason From: Scons-dev [mailto:scons-dev-boun...@scons.org] On Behalf Of anatoly techtonik Sent: Thursday, April 2, 2015 4:43 AM To: SCons developer list Subject: Re: [Scons-dev] Packaging logic? On Wed, Apr 1, 2015 at 6:22 PM, Bill Deegan b...@baddogconsulting.commailto:b...@baddogconsulting.com wrote: 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). This is a can of worms IMO. SCons is not tool for Python programmers, so if you do that, you will require people to learn about Python packaging, which is an unnecessary hell. If the tools is needed by Python programmers, then plz. state how exactly. Put the real world need first - what are you trying to achieve with that, excluding the consistency with Python world? The primary function and the way of using SCons for me (and my vision for everybody else) is to be a build tool that can be put into source repository, so that you can directly build after checkout without messing with apt-get/yum/pip install ... and friends. ___ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
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.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
Re: [Scons-dev] Packaging logic?
On Wed, Apr 1, 2015 at 11:39 AM, Kenny, Jason L jason.l.ke...@intel.com wrote: 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. Seems if you use virtualenv, this would be a non-issue.. I don't know much about wheel format. 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-boun...@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.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 ___ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
[Scons-dev] Packaging logic?
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
