[Scons-users] Windows batch file location in 2.5.1
Bill Deegan
bill at baddogconsulting.com
Thu Apr 6 19:08:16 EDT 2017
gotcha.
-Bill
On Thu, Apr 6, 2017 at 3:37 PM, Rob Boehne <robb at datalogics.com> wrote:
> We install a virtual environment in a directory named “python-env-`uname
> –n`”
> and the check that’s in get_scons_prefix() looks for “python*” in the
> prefix directory (in an attempt to identify python installs of the form:
> Z:\\Python27\\)
> and places things up one level from $(prefix)\Scripts if it finds a
> match. So, if we’d named our virtual environment directory
> “xython-env-$(uname –n)” then it wouldn’t match, and the batch files would
> go under \\Scripts\\
>
> From: Scons-users <scons-users-bounces at scons.org> on behalf of Bill
> Deegan <bill at baddogconsulting.com>
> Reply-To: SCons users mailing list <scons-users at scons.org>
> Date: Wednesday, April 5, 2017 at 7:34 PM
>
> To: SCons users mailing list <scons-users at scons.org>
> Subject: Re: [Scons-users] Windows batch file location in 2.5.1
>
> Rob,
>
> I'm a bit under caffeinated..
> What do you mean by
> "Apparently it’s triggered by naming the virtual environment directory..."
> The "it's" is what I'm unclear about. What is it in this context?
>
> Thanks,
> Bill
>
> On Wed, Apr 5, 2017 at 6:00 PM, Rob Boehne <robb at datalogics.com> wrote:
>
>> Apparently it’s triggered by naming the virtual environment directory
>> “python-env-%MACHINENAME%” which matches that pattern it’s looking for. I
>> tested this using pip-8 and pip-9, but the virtual environment hadn’t been
>> activated yet, is a “bootstrap” script that creates the virtual
>> environment, then installs modules into it. Let me know if you need me to
>> do anything else to get this change in.
>>
>> Thanks,
>>
>> Rob Boehne
>>
>> From: Scons-users <scons-users-bounces at scons.org> on behalf of Bill
>> Deegan <bill at baddogconsulting.com>
>> Reply-To: SCons users mailing list <scons-users at scons.org>
>> Date: Wednesday, April 5, 2017 at 4:52 PM
>> To: SCons users mailing list <scons-users at scons.org>
>> Subject: Re: [Scons-users] Windows batch file location in 2.5.1
>>
>> pip should work in virtualenv, but is broken if not in virtualenv I
>> believe.
>> You may also need a newer version of pip.
>> (BTW. that it's broken is a bug to be fixed hopefully soon. Focusing on
>> py2/3 port at the moment).
>>
>> Your change looks reasonable to me.
>>
>> Likely the setup.py will undergo some significant change going forward to
>> make it behave well with pip and also to simplify and bring more in line
>> with standard install practices.
>>
>> Alas the current setup.py is quite old and predates pip, virtualenv, etc..
>> (It used to work with python 1.5.x)
>>
>> -Bill
>>
>> On Wed, Apr 5, 2017 at 4:41 PM, Rob Boehne <robb at datalogics.com> wrote:
>>
>>> I’ve narrowed it down a little. I’m running “setup.py install” from
>>> another python script. If the user specifies —prefix=DIR then the two
>>> batch files in question will be installed in the correct location,
>>> $(DIR)/Scripts/. However, if the --root argument is used, or neither
>>> argument is used, then the batch files will be installed where they won’t
>>> find SCons modules.
>>>
>>> I believe the problem is in get_scons_prefix() which does some special
>>> things under Windows.
>>> Line 222 makes “$(prefix)” with the string “python” in it very special,
>>> in that it will decide to put batch files here, rather than the Scripts
>>> directory.
>>> if tail.lower()[:6] == "python”:
>>>
>>> One alternative would be to use:
>>> os.sep.join(sys.executable.split(os.sep)[:-1])
>>>
>>> However, as I look at what other packages do, I see most of them install
>>> similar things to Scripts, which is also included in the PATH by the
>>> installer. The batch files will function when installed in either location
>>> in a system-wide windows install, but they do not work in the current
>>> location when installed in a virtual environment. I’m of the opinion that
>>> this special treatment under windows should just be removed. Perhaps like
>>> this:
>>>
>>> diff -u setup.py.orig setup.py
>>> --- setup.py.orig2017-04-05 15:39:21.418584000 -0500
>>> +++ setup.py2017-04-05 15:39:50.262439900 -0500
>>> @@ -331,13 +331,9 @@
>>> create_basename_script(src, scons, scons_ver)
>>>
>>> if Options.install_bat:
>>> - if is_win32:
>>> - bat_install_dir = get_scons_prefix(self.install_dir,
>>> is_win32)
>>> - else:
>>> - bat_install_dir = self.install_dir
>>> for src in bat_scripts:
>>> - scons_bat = os.path.join(bat_install_dir, 'scons.bat')
>>> - scons_version_bat = os.path.join(bat_install_dir,
>>> + scons_bat = os.path.join(self.install_dir, 'scons.bat')
>>> + scons_version_bat = os.path.join(self.install_dir,
>>> 'scons-' + Version +
>>> '.bat')
>>> self.copy_scons(src, scons_bat)
>>> self.copy_scons(src, scons_version_bat)
>>>
>>>
>>> As I recall, pip was documented to not work for scons installations,
>>> which is why I use this method for scons and none of the other packages I
>>> install in this script. We use this on Windows, solaris, HP-UX, AIX, Linux
>>> and Mac OS X, so I need a method that will work for all of these
>>> platforms. When I attempt to install via pip, I get this error:
>>>
>>> Processing c:\users\robb\development\apdfl-15box\py27pkgs\scons-2.5.1.t
>>> ar.gz
>>> Installing collected packages: scons
>>> Running setup.py install for scons ... error
>>> Complete output from command c:\users\robb\development\apdf
>>> l-15box\python-env-robb-win8-vm\scripts\python.exe -u -c "import
>>> setuptools,
>>> tokenize;__file__='c:\\users\\robb\\appdata\\local\\temp\\pi
>>> p-uenvar-build\\setup.py';f=getattr(tokenize, 'open',
>>> open)(__file__);code=f.read().replace('\r\n',
>>> '\n');f.close();exec(compile(code, __file__, 'exec'))" install --record
>>> c:\users\robb\appdata\local\temp\pip-hg_3sq-record\install-record.txt
>>> --single-version-externally-managed --compile --install-headers
>>> c:\users\robb\development\apdfl-15box\python-env-robb-win8-v
>>> m\include\site\python2.7\scons:
>>> usage: -c [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
>>> or: -c --help [cmd1 cmd2 ...]
>>> or: -c --help-commands
>>> or: -c cmd --help
>>>
>>> error: option --single-version-externally-managed not recognized
>>>
>>> ----------------------------------------
>>> Command "c:\users\robb\development\apdfl-15box\python-env-robb-win8-vm\scripts\python.exe
>>> -u -c "import setuptools, tokenize;__file__='c:\\users\\
>>> robb\\appdata\\local\\temp\\pip-uenvar-build\\setup.py';f=getattr(tokenize,
>>> 'open', open)(__file__);code=f.read().replace('\r\n',
>>> '\n');f.close();exec(compile(code, __file__, 'exec'))" install --record
>>> c:\users\robb\appdata\local\temp\pip-hg_3sq-record\install-record.txt
>>> --single-version-externally-managed --compile --install-headers
>>> c:\users\robb\development\apdfl-15box\python-env-robb-win8-v
>>> m\include\site\python2.7\scons" failed with error code 1 in
>>> c:\users\robb\appdata\local\temp\pip-uenvar-build\
>>> Traceback (most recent call last):
>>> File "bootstrap.py", line 367, in <module>
>>> main(sys.argv)
>>> File "bootstrap.py", line 85, in main
>>> pip_install(*arg_list)
>>> File "bootstrap.py", line 360, in pip_install
>>> subprocess.check_call(run_pip + ['install',] + list(packageargs))
>>> File "c:\Python27\lib\subprocess.py", line 541, in check_call
>>> raise CalledProcessError(retcode, cmd)
>>> subprocess.CalledProcessError: Command '['C:\\Users\\robb\\Developmen
>>> t\\apdfl-15box\\python-env-robb-win8-vm\\Scripts\\pip.exe', 'install',
>>> 'file://C:\\Users\\robb\\Development\\apdfl-15box\\py27pkgs\\scons-2.5.1.tar.gz']'
>>> returned non-zero exit status 1
>>>
>>>
>>>
>>> From: Scons-users <scons-users-bounces at scons.org> on behalf of Bill
>>> Deegan <bill at baddogconsulting.com>
>>> Reply-To: SCons users mailing list <scons-users at scons.org>
>>> Date: Wednesday, April 5, 2017 at 12:34 PM
>>>
>>> To: SCons users mailing list <scons-users at scons.org>
>>> Subject: Re: [Scons-users] Windows batch file location in 2.5.1
>>>
>>> No. Actually the bug procedure (as it stands), is to wait from someone
>>> (hopefully a core dev) to confirm that it is a new bug, and not user error
>>> or a duplicate of an existing bug.
>>>
>>> So is your install via:
>>>
>>> python (from your virtualenv) setup.py install?
>>>
>>> Have you tried a pip install?
>>>
>>> -Bill
>>>
>>>
>>>
>>> On Wed, Apr 5, 2017 at 7:43 AM, Thomas Berg <merlin66b at gmail.com> wrote:
>>>
>>>> I think the procedure is that you register it on the issue list
>>>> yourself:
>>>> http://scons.tigris.org/bug-submission.html
>>>>
>>>> Ideally one of the devs should maybe confirm that it is a bug first,
>>>> but...
>>>>
>>>> - Thomas
>>>>
>>>>
>>>> On Tue, Apr 4, 2017 at 10:24 PM, Rob Boehne <robb at datalogics.com>
>>>> wrote:
>>>>
>>>>> Well, because the documented setup method is “python setup.py
>>>>> install”, I incorporated that into the python script we use to bootstrap.
>>>>> This script is used on all platforms, and there’s not much in the way of
>>>>> platform-specific sections of code there. To use a different installer I
>>>>> would need to do add the windows-only installer to my repository and then
>>>>> add windows-only code to run the installer (and not run “python setup.py
>>>>> install”) when it’s running under windows.
>>>>>
>>>>> So… Can a dev add this to the issue list? I will look into fixing it
>>>>> and submit a patch.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Rob
>>>>>
>>>>>
>>>>> From: Scons-users <scons-users-bounces at scons.org> on behalf of Thomas
>>>>> Berg <merlin66b at gmail.com>
>>>>> Reply-To: SCons users mailing list <scons-users at scons.org>
>>>>> Date: Tuesday, April 4, 2017 at 2:45 PM
>>>>> To: SCons users mailing list <scons-users at scons.org>
>>>>> Subject: Re: [Scons-users] Windows batch file location in 2.5.1
>>>>>
>>>>> Hi,
>>>>>
>>>>> I'm a scons user too, and while I have not noticed problems with such
>>>>> installations, I have noticed that it makes a difference whether you use
>>>>> 'python setup.py install' in a source distribution, or use the executable
>>>>> scons installer. The installer still places scons batch files under Scripts
>>>>> and the actual scons library under Lib/site-packages, while setup.py
>>>>> installs it like you describe. I asked about it once on this mailing list,
>>>>> but this particular issue was not answered.
>>>>>
>>>>> It caused issues for me, because in my case I had parallel
>>>>> installations of different scons versions. Normally this works without
>>>>> issues, as versioned .bat files would be installed, and the unversioned one
>>>>> was always the latest one. But when the unversioned one suddenly went to a
>>>>> different location, it is whichever version that is first in PATH that gets
>>>>> run (in my case the older one).
>>>>>
>>>>> There is now a working 64 bit installer for windows on the sourceforge
>>>>> page, so one can always use the installer to install scons. That's what I
>>>>> use to make sure scons is always installed under Scripts.
>>>>>
>>>>> Cheers,
>>>>> Thomas
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Apr 4, 2017 at 8:42 PM, Rob Boehne <robb at datalogics.com>
>>>>> wrote:
>>>>>
>>>>>> Scons users,
>>>>>>
>>>>>> I recently upgraded from a paleolithic version of scons for a
>>>>>> cross-platform build system to scons 2.5.1.
>>>>>> We use a virtual environment to allow us to have multiple versions of
>>>>>> our build system, and everything is perfectly peachy except for Windows.
>>>>>> In the old version 0.97, scons installs scripts (batch files) under
>>>>>> the virtual environment’s “Scripts” directory on Windows.
>>>>>> Scons 2.5.1 puts them in the root directory, and they fail because
>>>>>> they don’t seem to set up the python paths correctly. If I move those
>>>>>> batch files from the top level down to “Scripts” they do find the paths
>>>>>> correctly.
>>>>>>
>>>>>> Because the paths don’t seem to be correct, I’m thinking these batch
>>>>>> files are getting installed in the wrong location. Has anyone else noticed
>>>>>> this?
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Rob Boehne
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Scons-users mailing list
>>>>>> Scons-users at scons.org
>>>>>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Scons-users mailing list
>>>>> Scons-users at scons.org
>>>>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> Scons-users mailing list
>>>> Scons-users at scons.org
>>>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Scons-users mailing list
>>> Scons-users at scons.org
>>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>
>>>
>>
>> _______________________________________________
>> Scons-users mailing list
>> Scons-users at scons.org
>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>
>>
>
> _______________________________________________
> Scons-users mailing list
> Scons-users at scons.org
> https://pairlist4.pair.net/mailman/listinfo/scons-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20170406/dbfa5d3d/attachment-0001.html>
More information about the Scons-users
mailing list