Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #104228 > unrolled thread

Re: Question

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Question Ian Kelly <ian.g.kelly@gmail.com> - 2016-03-07 09:57 -0700
    Re: Question Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2016-03-07 18:09 +0000
      Re: Question mm0fmf <none@invalid.com> - 2016-03-07 18:18 +0000
        Re: Question Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2016-03-07 18:51 +0000
          Re: Question Ian Kelly <ian.g.kelly@gmail.com> - 2016-03-07 12:29 -0700
            Re: Question Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2016-03-08 01:41 +0000
              Re: Question justin walters <walters.justin01@gmail.com> - 2016-03-07 17:59 -0800
                Re: Question Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2016-03-08 10:24 +0000
                  Re: Question justin walters <walters.justin01@gmail.com> - 2016-03-08 08:47 -0800
                    Re: Question Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2016-03-08 16:53 +0000
              Re: Question Ian Kelly <ian.g.kelly@gmail.com> - 2016-03-08 10:19 -0700
                Re: Question Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2016-03-08 17:56 +0000
                  Re: Question Ian Kelly <ian.g.kelly@gmail.com> - 2016-03-08 11:08 -0700
                    Re: Question Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2016-03-08 18:08 +0000
                Re: Question Steven D'Aprano <steve@pearwood.info> - 2016-03-09 10:52 +1100
                  Re: Question Chris Angelico <rosuav@gmail.com> - 2016-03-09 11:13 +1100
                  Re: Question Ian Kelly <ian.g.kelly@gmail.com> - 2016-03-08 18:27 -0700
                    Re: Question Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2016-03-09 12:28 +0000
                      Re: Question Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2016-03-09 23:01 -0500
                        Re: Question Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2016-03-10 11:44 +0000
                          Re: Question Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2016-03-10 08:37 -0500
                  Re: Question Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2016-03-09 12:52 +0000
          Re: Question Chris Angelico <rosuav@gmail.com> - 2016-03-08 06:47 +1100
            Re: Question Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2016-03-08 01:33 +0000
          Re: Question Andrew Farrell <amfarrell@mit.edu> - 2016-03-07 14:00 -0600
          Re: Question justin walters <walters.justin01@gmail.com> - 2016-03-07 11:04 -0800
      Re: Question Chris Warrick <kwpolska@gmail.com> - 2016-03-07 19:22 +0100
      Re: Question Random832 <random832@fastmail.com> - 2016-03-07 13:26 -0500

Page 1 of 2  [1] 2  Next page →

#104228 — Re: Question

On Mon, Mar 7, 2016 at 9:39 AM, Ben Morales <grupopetra2010@gmail.com> wrote:
> I am trying to download Python but I have windows 10 and I do not see a 64
> bit download for my operating system. Do you have a 64 bit for windows?

What page are you looking at?
https://www.python.org/downloads/release/python-351/ has downloads for
both Windows x86 and Windows x86-64.

The other question is are you sure that 64-bit Python is what you
want? If your Python is 64-bit then I believe that any extension
modules you use need to be compiled 64-bit as well. On a 64-bit
Windows system you can run either 32-bit or 64-bit Python, and AFAIK
it's more common to use 32-bit Python.

[toc] | [next] | [standalone]

#104237

On 2016-03-07, Ian Kelly <ian.g.kelly@gmail.com> wrote:
> On Mon, Mar 7, 2016 at 9:39 AM, Ben Morales <grupopetra2010@gmail.com> wrote:
>> I am trying to download Python but I have windows 10 and I do not see a 64
>> bit download for my operating system. Do you have a 64 bit for windows?
>
> What page are you looking at?
> https://www.python.org/downloads/release/python-351/ has downloads for
> both Windows x86 and Windows x86-64.

It only appears to have downloads for 32-bit, or 64-bit AMD processors,
not 64-bit Intel processors.

[toc] | [prev] | [next] | [standalone]

#104239

On 07/03/2016 18:09, Jon Ribbens wrote:
> On 2016-03-07, Ian Kelly <ian.g.kelly@gmail.com> wrote:
>> On Mon, Mar 7, 2016 at 9:39 AM, Ben Morales <grupopetra2010@gmail.com> wrote:
>>> I am trying to download Python but I have windows 10 and I do not see a 64
>>> bit download for my operating system. Do you have a 64 bit for windows?
>>
>> What page are you looking at?
>> https://www.python.org/downloads/release/python-351/ has downloads for
>> both Windows x86 and Windows x86-64.
>
> It only appears to have downloads for 32-bit, or 64-bit AMD processors,
> not 64-bit Intel processors.
>

You didn't read the bit that says

"The binaries for AMD64 will also work on processors that implement the 
Intel 64 architecture. (Also known as the "x64" architecture, and 
formerly known as both "EM64T" and "x86-64".) "

[toc] | [prev] | [next] | [standalone]

#104244

On 2016-03-07, mm0fmf <none@invalid.com> wrote:
> On 07/03/2016 18:09, Jon Ribbens wrote:
>> It only appears to have downloads for 32-bit, or 64-bit AMD processors,
>> not 64-bit Intel processors.
>
> You didn't read the bit that says
>
> "The binaries for AMD64 will also work on processors that implement the 
> Intel 64 architecture. (Also known as the "x64" architecture, and 
> formerly known as both "EM64T" and "x86-64".) "

You are quite correct that I did not read the whole of the
ridiculously-long and badly-organised download page.

I would strongly suggest that, at the very least, the 'Description'
for the x86-64 files should say "for all 64-bit PCs (except Itanium*)"
with the '*' linking to a footnote that explains how to tell if you
have one of those.

I must say that Python on Windows was a very poor experience indeed,
"virtualenv" does not work and "venv" refuses to create the 'activate'
shell script so does not work either (and pygame doesn't work, but
that's presumably not Python's fault).

[toc] | [prev] | [next] | [standalone]

#104248

On Mon, Mar 7, 2016 at 11:51 AM, Jon Ribbens
<jon+usenet@unequivocal.co.uk> wrote:
> I must say that Python on Windows was a very poor experience indeed,
> "virtualenv" does not work and "venv" refuses to create the 'activate'
> shell script so does not work either

I've used both of these on Windows (although not recently) and had no
trouble with them. I never had a problem with venv not creating the
activate.bat file.

[toc] | [prev] | [next] | [standalone]

#104304

On 2016-03-07, Ian Kelly <ian.g.kelly@gmail.com> wrote:
> On Mon, Mar 7, 2016 at 11:51 AM, Jon Ribbens
><jon+usenet@unequivocal.co.uk> wrote:
>> I must say that Python on Windows was a very poor experience indeed,
>> "virtualenv" does not work and "venv" refuses to create the 'activate'
>> shell script so does not work either
>
> I've used both of these on Windows (although not recently) and had no
> trouble with them. I never had a problem with venv not creating the
> activate.bat file.

It's not activate.bat, it's activate (no file extension) the posix
shell script. I installed Git for Windows which provides bash (or
something that looks like it). Python venv doesn't cope with this
situation at all.

'virtualenv' works even less well, it just says:

$ virtualenv test
Using base prefix 'd:\\program files (x86)\\python35-32'
New python executable in D:\Users\Jon Ribbens\Documents\Python\test\Scripts\python.exe
ERROR: The executable "D:\Users\Jon Ribbens\Documents\Python\test\Scripts\python.exe" could not be run: [WinError 5] Access is denied

[toc] | [prev] | [next] | [standalone]

#104309

Well, from that error message, it seems like you may have a permissions
issue. Also, the git shell is not the sane as a real shell. There are
multiple windows terminal emulators. Why not use one of those?
On Mar 7, 2016 5:46 PM, "Jon Ribbens" <jon+usenet@unequivocal.co.uk> wrote:

> On 2016-03-07, Ian Kelly <ian.g.kelly@gmail.com> wrote:
> > On Mon, Mar 7, 2016 at 11:51 AM, Jon Ribbens
> ><jon+usenet@unequivocal.co.uk> wrote:
> >> I must say that Python on Windows was a very poor experience indeed,
> >> "virtualenv" does not work and "venv" refuses to create the 'activate'
> >> shell script so does not work either
> >
> > I've used both of these on Windows (although not recently) and had no
> > trouble with them. I never had a problem with venv not creating the
> > activate.bat file.
>
> It's not activate.bat, it's activate (no file extension) the posix
> shell script. I installed Git for Windows which provides bash (or
> something that looks like it). Python venv doesn't cope with this
> situation at all.
>
> 'virtualenv' works even less well, it just says:
>
> $ virtualenv test
> Using base prefix 'd:\\program files (x86)\\python35-32'
> New python executable in D:\Users\Jon
> Ribbens\Documents\Python\test\Scripts\python.exe
> ERROR: The executable "D:\Users\Jon
> Ribbens\Documents\Python\test\Scripts\python.exe" could not be run:
> [WinError 5] Access is denied
> --
> https://mail.python.org/mailman/listinfo/python-list
>

[toc] | [prev] | [next] | [standalone]

#104326

On 2016-03-08, justin walters <walters.justin01@gmail.com> wrote:
> Well, from that error message, it seems like you may have a permissions
> issue.

If that's true then it means the Python 3.5 installer is broken.
However, I don't think it is true as actually running Python presents
no problems. There's some bug in virtualenv which is making it return
a permissions error when there is none.

> Also, the git shell is not the sane as a real shell. There are
> multiple windows terminal emulators. Why not use one of those?

I am - the git shell.

I wanted to run a Python project that's hosted on github,
so I downloaded Python and Git for Windows - why would
anyone do otherwise?

[toc] | [prev] | [next] | [standalone]

#104343

My apologies, but I really don't want to argue with you. You may want to be
a bit more humble when asking for help.
On Mar 8, 2016 2:31 AM, "Jon Ribbens" <jon+usenet@unequivocal.co.uk> wrote:

> On 2016-03-08, justin walters <walters.justin01@gmail.com> wrote:
> > Well, from that error message, it seems like you may have a permissions
> > issue.
>
> If that's true then it means the Python 3.5 installer is broken.
> However, I don't think it is true as actually running Python presents
> no problems. There's some bug in virtualenv which is making it return
> a permissions error when there is none.
>
> > Also, the git shell is not the sane as a real shell. There are
> > multiple windows terminal emulators. Why not use one of those?
>
> I am - the git shell.
>
> I wanted to run a Python project that's hosted on github,
> so I downloaded Python and Git for Windows - why would
> anyone do otherwise?
> --
> https://mail.python.org/mailman/listinfo/python-list
>

[toc] | [prev] | [next] | [standalone]

#104345

On 2016-03-08, justin walters <walters.justin01@gmail.com> wrote:
> My apologies, but I really don't want to argue with you.

That's nice to know. I didn't ask you to, but it's great to have your
input anyway.

> You may want to be a bit more humble when asking for help.

I wasn't asking for help. HTH.

[toc] | [prev] | [next] | [standalone]

#104349

On Mon, Mar 7, 2016 at 6:41 PM, Jon Ribbens
<jon+usenet@unequivocal.co.uk> wrote:
> On 2016-03-07, Ian Kelly <ian.g.kelly@gmail.com> wrote:
>> On Mon, Mar 7, 2016 at 11:51 AM, Jon Ribbens
>><jon+usenet@unequivocal.co.uk> wrote:
>>> I must say that Python on Windows was a very poor experience indeed,
>>> "virtualenv" does not work and "venv" refuses to create the 'activate'
>>> shell script so does not work either
>>
>> I've used both of these on Windows (although not recently) and had no
>> trouble with them. I never had a problem with venv not creating the
>> activate.bat file.
>
> It's not activate.bat, it's activate (no file extension) the posix
> shell script. I installed Git for Windows which provides bash (or
> something that looks like it). Python venv doesn't cope with this
> situation at all.

Well, running bash on Windows is decidedly non-standard. This is like
installing a Python package on a Linux system and then complaining
that it won't run under wine. I don't think that Python should be
expected to provide an activate script for all possible shells the
user might conceivably want to use.

> 'virtualenv' works even less well, it just says:
>
> $ virtualenv test
> Using base prefix 'd:\\program files (x86)\\python35-32'
> New python executable in D:\Users\Jon Ribbens\Documents\Python\test\Scripts\python.exe
> ERROR: The executable "D:\Users\Jon Ribbens\Documents\Python\test\Scripts\python.exe" could not be run: [WinError 5] Access is denied

Ah, I probably never tried using it inside a user dir. On Windows I
typically do development in a path close to the drive root, e.g.
C:\dev.

[toc] | [prev] | [next] | [standalone]

#104352

On 2016-03-08, Ian Kelly <ian.g.kelly@gmail.com> wrote:
> On Mon, Mar 7, 2016 at 6:41 PM, Jon Ribbens
><jon+usenet@unequivocal.co.uk> wrote:
>> It's not activate.bat, it's activate (no file extension) the posix
>> shell script. I installed Git for Windows which provides bash (or
>> something that looks like it). Python venv doesn't cope with this
>> situation at all.
>
> Well, running bash on Windows is decidedly non-standard. This is like
> installing a Python package on a Linux system and then complaining
> that it won't run under wine.

I would agree with this, except that git seems to think it *is*
standard, and git itself seems pretty standard these days, so if
git thinks it's standard then disagreeing with them seems a bit
pointless.

> I don't think that Python should be expected to provide an activate
> script for all possible shells the user might conceivably want to
> use.

I would agree with this too, except that the shell script clearly
is already implemented for Unix purposes and would do no harm if
written to the directory, so presumably all 'venv' needs to do is to
stop preventing itself doing something it already knows how to do.

>> $ virtualenv test
>> Using base prefix 'd:\\program files (x86)\\python35-32'
>> New python executable in D:\Users\Jon Ribbens\Documents\Python\test\Scripts\python.exe
>> ERROR: The executable "D:\Users\Jon Ribbens\Documents\Python\test\Scripts\python.exe" could not be run: [WinError 5] Access is denied
>
> Ah, I probably never tried using it inside a user dir. On Windows I
> typically do development in a path close to the drive root, e.g.
> C:\dev.

The only things I can think of that are at all 'weird' are that there
are spaces in the filenames, and there's more than one drive. But
the former of those is utterly standard for Windows, and the latter
doesn't really even rise to the level of 'uncommon', let alone truly
unusual. If I'm seeing these problems then thousands of other people
must have already seen them before me.

[toc] | [prev] | [next] | [standalone]

#104353

On Tue, Mar 8, 2016 at 10:56 AM, Jon Ribbens
<jon+usenet@unequivocal.co.uk> wrote:
> The only things I can think of that are at all 'weird' are that there
> are spaces in the filenames, and there's more than one drive. But
> the former of those is utterly standard for Windows, and the latter
> doesn't really even rise to the level of 'uncommon', let alone truly
> unusual. If I'm seeing these problems then thousands of other people
> must have already seen them before me.

The other difference is that files and folders inside Windows user
dirs get created with implicit permissions settings, and the issue
does appear to be permissions-related.

[toc] | [prev] | [next] | [standalone]

#104354

On 2016-03-08, Ian Kelly <ian.g.kelly@gmail.com> wrote:
> On Tue, Mar 8, 2016 at 10:56 AM, Jon Ribbens
><jon+usenet@unequivocal.co.uk> wrote:
>> The only things I can think of that are at all 'weird' are that there
>> are spaces in the filenames, and there's more than one drive. But
>> the former of those is utterly standard for Windows, and the latter
>> doesn't really even rise to the level of 'uncommon', let alone truly
>> unusual. If I'm seeing these problems then thousands of other people
>> must have already seen them before me.
>
> The other difference is that files and folders inside Windows user
> dirs get created with implicit permissions settings, and the issue
> does appear to be permissions-related.

That's interesting, maybe that's the reason. It would certainly mean
that almost everyone who uses virtualenv with Python on Windows would
come up against this problem though - I mean, keeping your user files
under your own user home directory is hardly weird.

[toc] | [prev] | [next] | [standalone]

#104362

On Wed, 9 Mar 2016 04:19 am, Ian Kelly wrote:

> On Mon, Mar 7, 2016 at 6:41 PM, Jon Ribbens
> <jon+usenet@unequivocal.co.uk> wrote:
>> On 2016-03-07, Ian Kelly <ian.g.kelly@gmail.com> wrote:
>>> On Mon, Mar 7, 2016 at 11:51 AM, Jon Ribbens
>>><jon+usenet@unequivocal.co.uk> wrote:
>>>> I must say that Python on Windows was a very poor experience indeed,

Indeed. Development on Windows platforms is, sadly, a second-class
experience in general compared to POSIX-compatible platforms, and Python is
no different.

That's not to say that you can't do good work on Windows, but it is harder
and most costly.


>>>> "virtualenv" does not work and "venv" refuses to create the 'activate'
>>>> shell script so does not work either
>>>
>>> I've used both of these on Windows (although not recently) and had no
>>> trouble with them. I never had a problem with venv not creating the
>>> activate.bat file.
>>
>> It's not activate.bat, it's activate (no file extension) the posix
>> shell script. I installed Git for Windows which provides bash (or
>> something that looks like it). Python venv doesn't cope with this
>> situation at all.
> 
> Well, running bash on Windows is decidedly non-standard. This is like
> installing a Python package on a Linux system and then complaining
> that it won't run under wine. I don't think that Python should be
> expected to provide an activate script for all possible shells the
> user might conceivably want to use.

Not "all possible shells", no. But it's not unreasonable for it to handle
the single most popular operating system environment in the world, Windows,
don't you think?

I'm sure that if somebody cared enough to report this on the bug tracker, it
would be fixed. Steve Dower works for Microsoft, and he's doing what he can
to improve the Python-on-Windows experience. (Microsoft actually do
consider Python to be an important, if minor, part of their development
ecosystem.)


>> 'virtualenv' works even less well, it just says:
>>
>> $ virtualenv test
>> Using base prefix 'd:\\program files (x86)\\python35-32'
>> New python executable in D:\Users\Jon
>> Ribbens\Documents\Python\test\Scripts\python.exe ERROR: The executable
>> "D:\Users\Jon Ribbens\Documents\Python\test\Scripts\python.exe" could not
>> be run: [WinError 5] Access is denied
> 
> Ah, I probably never tried using it inside a user dir. On Windows I
> typically do development in a path close to the drive root, e.g.
> C:\dev.


Am I missing something? It looks to me like a straight forward permissions
error? I don't know how difficult that is to solve on Windows, but I don't
think it has anything to do with the path itself, only the permissions of
the path.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#104366

On Wed, Mar 9, 2016 at 10:52 AM, Steven D'Aprano <steve@pearwood.info> wrote:
>> Well, running bash on Windows is decidedly non-standard. This is like
>> installing a Python package on a Linux system and then complaining
>> that it won't run under wine. I don't think that Python should be
>> expected to provide an activate script for all possible shells the
>> user might conceivably want to use.
>
> Not "all possible shells", no. But it's not unreasonable for it to handle
> the single most popular operating system environment in the world, Windows,
> don't you think?

I'm not sure that the issue is "Windows can't use venv", but "Windows
with Git Bash can't use venv". Windows has a number of shells
available; the default one is pretty terrible but does kinda work, and
then there's PowerShell, and ports of other shells like bash. Cygwin
provides its own shell (which I think is bash), and I'm not sure if
that's the same as Git Bash installs. And then there's the difference
between the shell (the command interpreter) and the, for want of a
better name, terminal emulator (the thing that displays stuff on the
screen).

Working purely within cmd.exe and the default terminal emulator, I was
able to "py -m venv env" and then "env\scripts\activate" (note, *not*
env/bin/activate which is what I'm used to - no idea why). It seemed
to work.

Working instead in Git Bash, though, leaves me unable to activate,
because there is no bash script for venv activation. Hence, the
problem is "supporting all possible shells" (which is an enormous
challenge), rather than "supporting one of the three most popular
operating systems" (which, I agree, is well worth doing).

ChrisA

[toc] | [prev] | [next] | [standalone]

#104373

On Tue, Mar 8, 2016 at 5:13 PM, Chris Angelico <rosuav@gmail.com> wrote:
> On Wed, Mar 9, 2016 at 10:52 AM, Steven D'Aprano <steve@pearwood.info> wrote:
>>> Well, running bash on Windows is decidedly non-standard. This is like
>>> installing a Python package on a Linux system and then complaining
>>> that it won't run under wine. I don't think that Python should be
>>> expected to provide an activate script for all possible shells the
>>> user might conceivably want to use.
>>
>> Not "all possible shells", no. But it's not unreasonable for it to handle
>> the single most popular operating system environment in the world, Windows,
>> don't you think?
>
> I'm not sure that the issue is "Windows can't use venv", but "Windows
> with Git Bash can't use venv". Windows has a number of shells
> available; the default one is pretty terrible but does kinda work, and
> then there's PowerShell, and ports of other shells like bash. Cygwin
> provides its own shell (which I think is bash), and I'm not sure if
> that's the same as Git Bash installs. And then there's the difference
> between the shell (the command interpreter) and the, for want of a
> better name, terminal emulator (the thing that displays stuff on the
> screen).
>
> Working purely within cmd.exe and the default terminal emulator, I was
> able to "py -m venv env" and then "env\scripts\activate" (note, *not*
> env/bin/activate which is what I'm used to - no idea why). It seemed
> to work.
>
> Working instead in Git Bash, though, leaves me unable to activate,
> because there is no bash script for venv activation. Hence, the
> problem is "supporting all possible shells" (which is an enormous
> challenge), rather than "supporting one of the three most popular
> operating systems" (which, I agree, is well worth doing).

It looks like the shell environment that comes with Git for Windows is
actually Windows Powershell [1], so presumably the activate.ps1 script
that's already provided by venv is what's needed, not a bash script.

Git Bash is apparently separate and runs under MinGW, which in my
limited experience could charitably be described as "semi-functional".
Admittedly, it's been a long while since the last time I tried to use
it. Cygwin is much better, and it emulates a POSIX platform so closely
that I wouldn't be surprised if a Python running under Cygwin simply
installed the bash venv script to begin with.

[1] https://git-scm.com/book/en/v2/Git-in-Other-Environments-Git-in-Powershell

[toc] | [prev] | [next] | [standalone]

#104404

On 2016-03-09, Ian Kelly <ian.g.kelly@gmail.com> wrote:
> It looks like the shell environment that comes with Git for Windows is
> actually Windows Powershell [1], so presumably the activate.ps1 script
> that's already provided by venv is what's needed, not a bash script.

This is not true. I installed Git for Windows and what it gave me was
"Git Bash" which as you say runs in a window titled "MINGW64".

If I try to run the activate.ps1 script it says:

$ env/Scripts/activate.ps1
env/Scripts/activate.ps1: line 1: syntax error near unexpected token `[switch]$NonDestructive'
env/Scripts/activate.ps1: line 1: `function global:deactivate ([switch]$NonDestructive) {'

[toc] | [prev] | [next] | [standalone]

#104472

On Wed, 9 Mar 2016 12:28:30 -0000 (UTC), Jon Ribbens
<jon+usenet@unequivocal.co.uk> declaimed the following:

>On 2016-03-09, Ian Kelly <ian.g.kelly@gmail.com> wrote:
>> It looks like the shell environment that comes with Git for Windows is
>> actually Windows Powershell [1], so presumably the activate.ps1 script
>> that's already provided by venv is what's needed, not a bash script.
>
>This is not true. I installed Git for Windows and what it gave me was
>"Git Bash" which as you say runs in a window titled "MINGW64".
>
>If I try to run the activate.ps1 script it says:
>
>$ env/Scripts/activate.ps1
>env/Scripts/activate.ps1: line 1: syntax error near unexpected token `[switch]$NonDestructive'
>env/Scripts/activate.ps1: line 1: `function global:deactivate ([switch]$NonDestructive) {'

	Which is no surprise, as .ps1 is a PowerShell script -- and even
PowerShell may not run it unless the system is configured to allow for
local unsigned scripts.

http://stackoverflow.com/questions/30577271/activating-pyvenv-from-gitbash-for-windows

-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

[toc] | [prev] | [next] | [standalone]

#104502

On 2016-03-10, Dennis Lee Bieber <wlfraed@ix.netcom.com> wrote:
> On Wed, 9 Mar 2016 12:28:30 -0000 (UTC), Jon Ribbens
><jon+usenet@unequivocal.co.uk> declaimed the following:
>>On 2016-03-09, Ian Kelly <ian.g.kelly@gmail.com> wrote:
>>> It looks like the shell environment that comes with Git for Windows is
>>> actually Windows Powershell [1], so presumably the activate.ps1 script
>>> that's already provided by venv is what's needed, not a bash script.
>>
>>This is not true. I installed Git for Windows and what it gave me was
>>"Git Bash" which as you say runs in a window titled "MINGW64".
>>
>>If I try to run the activate.ps1 script it says:
>>
>>$ env/Scripts/activate.ps1
>>env/Scripts/activate.ps1: line 1: syntax error near unexpected token `[switch]$NonDestructive'
>>env/Scripts/activate.ps1: line 1: `function global:deactivate ([switch]$NonDestructive) {'
>
> 	Which is no surprise, as .ps1 is a PowerShell script

Indeed, I was just pointing out that the shell Git for Windows
installed was definitely not Powershell (or at best, Powershell
is only one of the available options).

> http://stackoverflow.com/questions/30577271/activating-pyvenv-from-gitbash-for-windows

Yes, I tried the solution suggested there (copy the 'activate' script
from an existing Unix virtualenv) and unfortunately it didn't work
(it looked like it worked but 'pip install' still installed things in
the system packages directory not the virtualenv).

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.python

csiph-web