[issue38583] The activate script in Windows is not correct for venvs created in git-bash
Mark Mikofski added the comment:
Would you consider just handling activate for windows directly in the
lib/venv/__init__.py method "install_scripts(self, context, path)"
https://github.com/python/cpython/blob/4f98f465f14e7258c5b18a62c5aa114dbe1174d8/Lib/venv/__init__.py#L382
if not srcfile.endswith(('.exe', '.pdb')):
# handle activate for Windows (ignore WSL)
if srcfile == "activate":
# from docs: on unix drive is always empty
d, p = os.path.splitdrive(context.env_dir)
d = d.replace(':', '')
p = p.replace('\\', '/')
if d:
p = '/' + d + p
data = data.decode('utf-8')
data = data.replace('__VENV_DIR__', p)
data = data.encode('utf-8')
try:
data = data.decode('utf-8')
data = self.replace_variables(data, context)
data = data.encode('utf-8')
except UnicodeError as e:
IMHO I don't think the use of windows python in WSL is a realistic use-case, my
preference would be to just make this fail. In fact I tried to use it, and I
could not make it work.
1. /mnt/c/path/to/python -m venv venv
Error: [WinError 5] Access is denied: 'C:\\WINDOWS\\system32\\venv'
2. /mnt/c/path/to/python -m venv -m venv /mnt/c/some/path/to/venv
fails silently, appears to do nothing, venv is not created
3. /mnt/c/path/to/python -m venv -m venv 'C:/some/path/to/venv'
makes directories at C:\some\path\to\venv, but can't be activated in WSL, that
I can figure out
source /mnt/c/some/path/to/venv/Scripts/activate
: command not found
-bash: /mnt/c/some/path/to/venv/Scripts/activate: line 4: syntax error near
unexpected token `$'{\r''
'bash: /mnt/c/some/path/to/venv/Scripts/activate: line 4: `deactivate () {
I guess I don't really understand why it would be useful to use the windows
python in WSL, and if that's the only thing holding a quick fix for this, I
guess, I would prefer to just handle windows python in windows in git-bash, and
ignore WSL. Would you be open to that?
If so, I'm happy to submit a PR
thanks!
--
nosy: +bwanamarko
___
Python tracker
<https://bugs.python.org/issue38583>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34657] pyconfig.h macro "timezone" name clashes with user source are likely
New submission from Mark Mikofski : TL;DR: if PC user compiles source which defines "timezone" in a header, and includes Python.h after the header, then the macro also called "timezone" in pyconfig.h will redefine the users source, yielding unexpected results. see Cython google group for an actual use case where this occurred: https://groups.google.com/forum/#!topic/cython-users/pjbhYrpl_rU trying to compile NREL SPA code which has a header file with a struct with a timezone field fails with the following traceback: spa.h(88): error C2032: '__timezone': function cannot be member of struct '' here's the macro in PC/pyconfig.h in master as of 5489bdad https://github.com/python/cpython/blob/5489bdad5143050b8bb89b648b3c00d951b72d4f/PC/pyconfig.h#L202 /* VS 2015 defines these names with a leading underscore */ #if _MSC_VER >= 1900 #define timezone _timezone #define daylight _daylight #define tzname _tzname #endif -- components: Build messages: 325235 nosy: bwanamarko priority: normal severity: normal status: open title: pyconfig.h macro "timezone" name clashes with user source are likely type: enhancement versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue34657> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22516] Windows Installer won't - even when using "just for me"option
Mark Mikofski added the comment: I've set up AppVeyor CI (http://www.appveyor.com/) to build the latest tag in the 2.7 branch of cpython at https://hg.python.org/ and to deploy zip files of x86 and x64 standalone builds to http://breakingbytes.alwaysdata.net/PythonBootstrap/. The builds use a patched version of Tools/buildbot/external[-amd64].bat and PCbuild/batch.bat[ -p x64] with Windows 7 SDK (VS2008) and pass all rt.bat -q[ -x64] tests. The zipped file structure matches the standard release structure except that I didn't copy any of the Tools folders (pynche, i18n, ...) or Demos, and I put html files in the Doc folder instead of python27.chm. To make it standalone I put the MSVCR90 redistributables in the top level side by side (privately) with python27.dll, which is acceptable according to the VS2008 license (http://download.microsoft.com/documents/useterms/Visual%20Studio_2008%20Professional%20Edition_English_473a7e16-65dc-4cfb-8f44-ebdd93cb1d3d.pdf) as long as the distro has any LICENSE. It is also one of the 3 recommended practices for deploying Visual C++ applications (https://msdn.microsoft.com/en-us/library/zebw5zk9(v=vs.90).aspx) especially Redistributiong Visual C++ Files (https://msdn.microsoft.com/en-us/library/ms235299(v=vs.90).aspx). The current Python uses the merge modules (https://msdn.microsoft.com/en-us/library/ms235290(v=vs.90).aspx) which requires admin rights. "Installation of the WinSxS folder requires administrative user rights. If an installation is run by a user who does not have administrative rights, the Visual C++ assemblies cannot be installed, and applications that depend on those DLLs cannot run. The alternative redistribution approach is to install private side-by-side assemblies of a particular user application. For more information on deploying Visual C++ files as private assemblies see Redistributing Visual C++ Files." In addition to some glue script, I added an altered version of idle.bat for Scripts that points to pythonw.exe and Lib\idlelib\idle.pyw from the Scripts folder instead of from the Lib\idlelib folder. This lets users start idle if Scripts is on their path. The glue for the appveyor build and the webpage are both maintained on bitbucket. * https://bitbucket.org/breakingbytes/cpython/branch/PythonBootstrap * https://bitbucket.org/breakingbytes/breakingbytes.bitbucket.org I expect this release to have several major uses: * It can be used to install python-2.7 without admin rights on windows * It can be used to embed python-2.7 into standalone applications that depend on python since it has a fairly small footprint, 15MB compressed. * To use 32-bit and 64-bit versions of Python on the same machine, which is technically not impossible now, and would still require some managment Some future goals: * create a self extracting executable that performs some minor niceties such as ... - adding Python and scripts to the path - fixing any hardcoded paths in bundled executbles - associated .py with python.exe - running python -m ensurepip - getting some convenient packages for scidata like pandas, numpy, xlrd, etc. -- versions: +Python 2.7 -Python 3.5 ___ Python tracker <http://bugs.python.org/issue22516> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14458] Non-admin installation fails
Mark Mikofski added the comment: Anyone still following this issue, as I posted in issue22516, there is an embeddable zipped version of Python-2.7.X built from source using the PCbuild batch files and vc90 toolset for both x86 and x64 called Python Bootstrap: http://breakingbytes.alwaysdata.net/PythonBootstrap/ The redistributable msvcr90.dll's are all bundled side-by-side privately with python27.dll as recommended by Windows and does not violate any licensing eulas. The build passes all tests and pythonw.exe works perfectly. Try starting python27/Scripts/idle.bat. It ... just ... works ... No ... Admin ... rights ... required ... just ... unzip ... use ... FYI: doing an "administrative install" using msiexec /a (https://www.python.org/download/releases/2.4/msi/) just extracts the msi archive and creates a smaller msi package used to do a local install later. This means that your python launcher and shared library are depending on whatever redistributables you have. You can't install the merge modules into winsxs w/o elevated rights so ... Also look at Python-3.5 for an embeddable zip file (no admin rights required) altho I think it requires vcredist for vc100 freely available from microsoft. -- nosy: +bwanamarko ___ Python tracker <http://bugs.python.org/issue14458> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4945] json checks True/False by identity, not boolean value
Mark Mikofski added the comment: This is effecting IronPython as well, because .NET objects return copies not references. If a .NET assembly method is called from IronPython, its return is a copy, not a reference. Therefore the reference of a boolean return is not the same as the internal Python reference for that boolean, and the JSON encoder doesn't recognize the value as a boolean, but instead treats it as an integer, and returns `str(o)`, which for `True` is "True" and for `False` is "False". Then the decoder can't interpret the JSON object because true and false are capitalize, which is not in its spec. :( See my comment https://github.com/IronLanguages/main/issues/1033. The patch would solve this problem. A copy of a boolean will be equal to its value, ie False == False even if their references are not the same. -- nosy: +bwanamarko ___ Python tracker <http://bugs.python.org/issue4945> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25112] Windows installer assigns non-existent icons to Python file types
Mark Mikofski added the comment: +1 I just wasted at least an hour on this. :( should have checked bugs first. Google says nothing, so I thought I was going crazy. I saw that py.exe had only one icon and that Python.File had c:\windows\py.exe, 1 while Python.CompiledFile had C:\windows\py.exe, 2, so I thought that might be it, but I just wasn't sure. Are the Py2 and Py3 icons exactly the same? if so, then IMO just use the py.ico and pyc.ico icons in the DLLs folder as suggested -- nosy: +bwanamarko ___ Python tracker <http://bugs.python.org/issue25112> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14597] Cannot unload dll in ctypes until script exits
Mark Mikofski added the comment: I think I have this issue even after interpreter exits. My setup.py creates a .dll then later loads the dll for testing using ctypes. Subsequent runs of setup.py that would force rebuilding the .dll attempt to delete the old dll first if it exists, but I get permission denied. Oddly, if I put the load library call inside a function, then, after exiting the interpreter the dll can be deleted. Windos 7 x64 Python 2.7.10 Sorry if this is by design, a Windows feature, unrelated or the wrong issue. I search SO and these bugs, and only found answers related to unloading dll during script. -- nosy: +bwanamarko ___ Python tracker <http://bugs.python.org/issue14597> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14597] Cannot unload dll in ctypes until script exits
Mark Mikofski added the comment:
Snippets of "proprietary" code
`setup.py`
--
# run clean or build libraries if they don't exist
if 'clean' in sys.argv:
try:
os.remove(os.path.join(LIB_DIR, SOLPOSAM_LIB_FILE))
os.remove(os.path.join(LIB_DIR, SPECTRL2_LIB_FILE))
except OSError as err:
sys.stderr.write('%s\n' % err)
`core.py`
-
# load the DLL
solposAM_dll = ctypes.cdll.LoadLibrary(SOLPOSAMDLL)
_solposAM = solposAM_dll.solposAM
After deleting files, setup.py tries to build, then runs test_cdlls.py a
unittest that contains test_solposAM() that calls solposAM() and imports
core.py that contains solposAM.
Case 1:
---
I put the load library calls inside the function solposAM().
Function calls works as expected.
I am able to delete dlls after interpreter exits and restarts using os.remove()
Case 2:
---
I put the load library calls at the module level.
Function calls works as expected.
If I try to delete dlls after interpreter exits and restarts using os.remove()
I get access denied, but I can delete them from windows explorer.
--
___
Python tracker
<http://bugs.python.org/issue14597>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24872] Add /NODEFAULTLIB:MSVCRT to _msvccompiler
Mark Mikofski added the comment: still have the `link.exe` 1561 error without `extra_args=['/DLL']` issue. is there a patch? It goes in `distutils._msvccompiler` right? -- nosy: +bwanamarko ___ Python tracker <http://bugs.python.org/issue24872> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15795] Zipfile.extractall does not preserve file permissions
Mark Mikofski added the comment: same problem in 2.7.5 on Oracle Linux 7.2 -- nosy: +bwanamarko ___ Python tracker <http://bugs.python.org/issue15795> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22516] Windows Installer won't - even when using "just for me"option
Mark Mikofski added the comment: I know this issue is closed, but as there is no voting or plus 1, I'll add my support for allowing local installation of not just Python-3, but also Python-2.7. I'm not sure what is gained by adding this restriction, or how difficult it would be to allow users without admin rights to install official python.org locally? Where is the source that needs to be patched? IMO forcing Windows users with restricted rights to go to Anaconda, Enthought, or WinPython causes a fracture in the Python community, that decreases credibility for Windows users. Quoting Tim Peters from import this, "There should be one-- and preferably only one --obvious way to do it." not 3 or more ways. Having most new users installing Anaconda has many disadvantages: 1. Developement of an open source optimized version of NumPy (eg: using OpenBLAS) has a lower value proposition because users can just install Anaconda, which uses an unoptimized version of Intel MKL. Of course users can continue to get Christoph Gohlke's optimized MKL NumPy until he decides he doesn't want to anymore. 2. There will be two (or more) Python package indexes: PyPI, conda:binstar, binstar and pythonwheels. Do we really want Python packagers to have to upload to all of these repos? Which is the most current? etc. = less credibility for Python 3. There are/will be more than one python package installer and virtualenv tool: conda vs. pip/virtualev Are there any repeats of this issue/feature request? -- nosy: +bwanamarko ___ Python tracker <http://bugs.python.org/issue22516> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22516] Windows Installer won't - even when using "just for me"option
Mark Mikofski added the comment: one more note, NaCl (J. Morton), you can install from the msi to any directory you want by using the following from a command line opened to the folder where you have the installer: C:\path\to\msi\download> msiexec /a python-2.7.9.amd64.msi TARGETDIR=C:\Python27 or C:\path\to\msi\download> msiexec /a python-3.4.3.amd64.msi TARGETDIR=C:\Python34 -- ___ Python tracker <http://bugs.python.org/issue22516> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22516] Windows Installer won't - even when using "just for me"option
Mark Mikofski added the comment: 1. J morton: just install Anacondahttp://continuum.io/downloads 2. I will take a look at the msi and see if I can accommodate both installs in the same installer -- ___ Python tracker <http://bugs.python.org/issue22516> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22516] Windows Installer won't - even when using "just for me"option
Mark Mikofski added the comment: WinPython and miniconda are more current distros than portable python, and they come in both 32 & 64bit flavors. Portable python hasn't been updated recently and only offers 32 bit which is IMO worthless except for the bundle as app case, eg meld installer. I was going to suggest the same - if python.org can't support local installs (sans admin rights) b/c people will always look to it for direction, python.org should offer links to endorsed windows installer. I don't love it, but it will be familiar to windows users braving the open source world, similar to ruby which recommends winruby. Any endorsed distro **must** be built with msvc, so that all packages with extensions can be built. I don't care to support packages that depend on autotools. Why can't msvcrt90.dll amd python27.dll be bundled into install directory? Seems to solve case #1 (for personal use) and #2 (bundled as app)? No admin rights required, just unzip. Why would you want to move python to program files? Case #3 would be swell, would windows ever do that? If we assume windows distros are akin to *nix them perhaps we need to push the --user or --home=~/.local options and virtualenv. That seems to be the way conda is going. Ruby rvm is more like that as well. Especially if we are going to force users to start using 3.5. What is Microsoft's official position on python. are they officially supporting python on windows? Seems like it with newest April's and vcforpython27. BTW miniconda does not install all of the sci-data packages, only conda and python 2.7. works with pip and --home=~/.local scheme. Is this the future for windows users? We should reach a consensus I think -- ___ Python tracker <http://bugs.python.org/issue22516> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22516] Windows Installer won't - even when using "just for me"option
Mark Mikofski added the comment: J. Morton and anyone else needing a Python-2.7.9 Windows release to use without admin rights or to embed in a personal application can see my blog to roll there own or download one of the versions from my dropbox http://poquitopicante.blogspot.com/2015/03/building-python-x64-on-windows-7-with.html https://www.dropbox.com/s/wc2x2or2477f4as/Python27-x86_asbuilt.zip?dl=0 https://www.dropbox.com/s/bcmh11kha9go8t6/Python27-x64_asbuilt.zip?dl=0 -- ___ Python tracker <http://bugs.python.org/issue22516> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
