Issue #217: Cannot invoke top-level scripts unqualified in native Windows install (blais/beancount)
7 views
Skip to first unread message
Jeff
Feb 17, 2018, 12:31:10 AM2/17/18
to bean...@googlegroups.com
New issue 217: Cannot invoke top-level scripts unqualified in native Windows install
https://bitbucket.org/blais/beancount/issues/217/cannot-invoke-top-level-scripts
Jeff:
For native Windows use, the python scripts cannot be invoked directly as unqualified commands. Wrapper batch scripts installed alongside the python scripts could address this.
I just installed beancount natively on Windows 10 (i.e., sans Cygwin, sans Ubuntu on Windows), as follows:
1. Per https://wiki.python.org/moin/WindowsCompilers, Installed Build Tools for Visual Studio 2017. (Workload: Visual C++ build tools *only*; Optionals: Windows 10 SDK (10.0.16299.0) for Desktop C++ *only*)
2. Downloaded copy of current source from bitbucket.
3. `cmd> python -m venv env` (just to confirm it plays nice in a venv)
4. `cmd> env\Scripts\activate.bat`
5. `cmd> pip install --upgrade setuptools` (not strictly necessary, suggested by link above)
6. `cmd> pip install .\<path-to-beancount>`
This works fine and dumps `bean-*` files into `env\Scripts`. These files have no extension, and contain a shebang with absolute path to `c:\<path>\<to>\env\Scripts\python.exe`, which presumably does something useful under Cygwin/MinGW, but is not processed by Windows command prompt. So, I cannot invoke `bean-*` commands unqualified at this point.
I do not know what the python community's standard practice—if any—is for dealing with this, but the obvious (to me) simple fix is to create `bean-*.bat` files in parallel (e.g., `env\Scripts\bean-bake.bat`), with the following trivial contents:
```
@python %~dp0%~n0 %*
```
In case it's not obvious, this passes a file in the same directory, with same name (sans extension) to python, forwarding all command-line arguments.
For now, I did this locally, by hand. Since `C:\<path>\<to>\env\Scripts` was prepended to my path by the venv's `activate.bat`, I can invoke, e.g., `bean-example` or `bean-example.bat` unqualified.
It would be nice if this happened automatically. Perhaps it could be done on-the-fly by `setup.py`?
https://bitbucket.org/blais/beancount/issues/217/cannot-invoke-top-level-scripts
Jeff:
For native Windows use, the python scripts cannot be invoked directly as unqualified commands. Wrapper batch scripts installed alongside the python scripts could address this.
I just installed beancount natively on Windows 10 (i.e., sans Cygwin, sans Ubuntu on Windows), as follows:
1. Per https://wiki.python.org/moin/WindowsCompilers, Installed Build Tools for Visual Studio 2017. (Workload: Visual C++ build tools *only*; Optionals: Windows 10 SDK (10.0.16299.0) for Desktop C++ *only*)
2. Downloaded copy of current source from bitbucket.
3. `cmd> python -m venv env` (just to confirm it plays nice in a venv)
4. `cmd> env\Scripts\activate.bat`
5. `cmd> pip install --upgrade setuptools` (not strictly necessary, suggested by link above)
6. `cmd> pip install .\<path-to-beancount>`
This works fine and dumps `bean-*` files into `env\Scripts`. These files have no extension, and contain a shebang with absolute path to `c:\<path>\<to>\env\Scripts\python.exe`, which presumably does something useful under Cygwin/MinGW, but is not processed by Windows command prompt. So, I cannot invoke `bean-*` commands unqualified at this point.
I do not know what the python community's standard practice—if any—is for dealing with this, but the obvious (to me) simple fix is to create `bean-*.bat` files in parallel (e.g., `env\Scripts\bean-bake.bat`), with the following trivial contents:
```
@python %~dp0%~n0 %*
```
In case it's not obvious, this passes a file in the same directory, with same name (sans extension) to python, forwarding all command-line arguments.
For now, I did this locally, by hand. Since `C:\<path>\<to>\env\Scripts` was prepended to my path by the venv's `activate.bat`, I can invoke, e.g., `bean-example` or `bean-example.bat` unqualified.
It would be nice if this happened automatically. Perhaps it could be done on-the-fly by `setup.py`?
Reply all
Reply to author
Forward
0 new messages