Windows support #64

thebjorn · 2014-12-18T18:27:22Z

Bumpversion fails on windows because Unicode values are entered into the
environment (due to from __future__ import unicode_literals).

I cannot reproduce the problem on linux.

This is the error I'm seeing on windows before this change:

____ ERROR collecting tests.py _______
tests.py:36: in <module>
  call(["git", "--help"], shell=True) != 1,
c:\python27\Lib\subprocess.py:493: in call
  return Popen(*popenargs, **kwargs).wait()
c:\python27\Lib\subprocess.py:679: in __init__
  errread, errwrite)
c:\python27\Lib\subprocess.py:896: in _execute_child
  startupinfo)
E   TypeError: environment can only contain strings

Bumpversion fails on windows because Unicode values are entered into the environment (due to `from __future__ import unicode_literals`). I can not reproduce the problem on linux. This is the error I'm seeing on windows before this change: ____ ERROR collecting tests.py _______ tests.py:36: in <module> call(["git", "--help"], shell=True) != 1, c:\python27\Lib\subprocess.py:493: in call return Popen(*popenargs, **kwargs).wait() c:\python27\Lib\subprocess.py:679: in __init__ errread, errwrite) c:\python27\Lib\subprocess.py:896: in _execute_child startupinfo) E TypeError: environment can only contain strings

Python 3x doesn't like explicit "unicode", relying on implicit unicode from `from __future__ import unicode_literals` instead.

ionelmc · 2014-12-27T20:04:54Z

👍

peritus · 2015-01-09T17:12:21Z

it's a pretty obvious bug so perhaps it doesn't need a unit/regression test?

Even if that would be a valid excuse: A regression test would be great to make sure this bug isn't introduced again in a later version.

ionelmc · 2015-01-09T17:39:44Z

This could be easily tested by running in a subprocess for which you set PYTHONIOENCODING=ascii (or something weird like that, maybe C?) in the env.

ionelmc · 2015-01-09T17:41:01Z

I'm assuming that's the cause (non utf8 default encoding on Windows).

thebjorn · 2015-01-09T19:27:33Z

No, the bug here is that the code is attempting to store a Unicode key/value pair in the environment without encoding it. In this particular case it is possible to store the key/value as ascii (aka. a byte string). You can, of course, also use the platform calls to fetch/store Unicode in the environment, but that seems like a lot of work for no gain. That it works on linux is probably due to an automatic reinterpretation somewhere. (ps: I believe Windows uses ibm850 as the environment encoding, but that may be dependent on which country you're in..)

thebjorn · 2015-01-09T19:31:18Z

Even if that would be a valid excuse: A regression test would be great to make
sure this bug isn't introduced again in a later version.

To re-iterate: I cannot reproduce this problem on linux -- ie. there is no way to write a regression test that will catch this on linux that I'm aware of. Not a single test in the testsuite passes before this fix on Windows (is that a regression test when the CI system doesn't run the tests on Windows..?)

I'm not sure I understand what you would like me to do here..?

thebjorn · 2015-01-09T19:34:50Z

This could be easily tested by running in a subprocess for which you
set PYTHONIOENCODING=ascii (or something weird like that, maybe C?)
in the env.

Sounds interesting, but I'm afraid I don't get how this will work..? Care to elaborate?

ps: this is the line that is failing:

call(["git", "--help"], shell=True) != 1

which is before the first test.

ionelmc · 2015-01-09T20:16:57Z

On Fri, Jan 9, 2015 at 9:34 PM, Bjorn notifications@github.com wrote:

PYTHONIOENCODING

See:
https://docs.python.org/2/using/cmdline.html?highlight=pythonioencoding#envvar-PYTHONIOENCODING

Try and see what works.

Worth starting to use appveyor (windows CI), see
https://packaging.python.org/en/latest/appveyor.html#appveyor-yml

Thanks,
-- Ionel Cristian Mărieș, blog.ionelmc.ro

thebjorn · 2015-01-09T20:56:43Z

IIUC, then PYTHONIOENCODING only deals with stdin/sdout/stderr, while this problem is related to the environment. Even if that would let me specify a default encoding for the environment(*) what would the test need to do to be a regression test?

Just as a reality check here... is it really supposed to be this difficult to get a two-character fix for an obvious bug into bumpversion?

(*) you can see from https://github.com/python-git/python/blob/715a6e5035bb21ac49382772076ec4c630d6e960/Modules/posixmodule.c#L6652 that there is no encoding call in Python's putenv.

thebjorn · 2015-01-09T21:06:47Z

c:\srv>set PYTHONIOENCODING
Environment variable PYTHONIOENCODING not defined

c:\srv>python -c "import subprocess;subprocess.call('exit 42', env={u'hello':u'world'})"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "c:\python27\lib\subprocess.py", line 493, in call
    return Popen(*popenargs, **kwargs).wait()
  File "c:\python27\lib\subprocess.py", line 679, in __init__
    errread, errwrite)
  File "c:\python27\lib\subprocess.py", line 896, in _execute_child
    startupinfo)
TypeError: environment can only contain strings

c:\srv>set PYTHONIOENCODING=utf-8

c:\srv>python -c "import subprocess;subprocess.call('exit 42', env={u'hello':u'world'})"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "c:\python27\lib\subprocess.py", line 493, in call
    return Popen(*popenargs, **kwargs).wait()
  File "c:\python27\lib\subprocess.py", line 679, in __init__
    errread, errwrite)
  File "c:\python27\lib\subprocess.py", line 896, in _execute_child
    startupinfo)
TypeError: environment can only contain strings

c:\srv>

thebjorn · 2015-01-09T21:21:27Z

Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation.  All rights reserved.

c:\srv>vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Clearing any previously set forwarded ports...
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
    default: Adapter 1: nat
==> default: Forwarding ports...
    default: 80 => 9000 (adapter 1)
    default: 8000 => 8800 (adapter 1)
    default: 3306 => 4500 (adapter 1)
    default: 22 => 2222 (adapter 1)
==> default: Running 'pre-boot' VM customizations...
==> default: Booting VM...
==> default: Waiting for machine to boot. This may take a few minutes...
    default: SSH address: 127.0.0.1:2222
    default: SSH username: vagrant
    default: SSH auth method: private key
    default: Warning: Connection timeout. Retrying...
==> default: Machine booted and ready!
==> default: Checking for guest additions in VM...
==> default: Mounting shared folders...
    default: /vagrant => C:/srv
==> default: Machine already provisioned. Run `vagrant provision` or use the `--provision`
==> default: to force provisioning. Provisioners marked to run always will still run.

c:\srv>vagrant ssh
Welcome to Ubuntu 12.04 LTS (GNU/Linux 3.2.0-23-generic x86_64)

 * Documentation:  https://help.ubuntu.com/
New release '14.04.1 LTS' available.
Run 'do-release-upgrade' to upgrade to it.

Welcome to your Vagrant-built virtual machine.
Last login: Sat Dec 20 01:49:45 2014 from 10.0.2.2
vagrant@precise64:~$ python -c "import subprocess;subprocess.call('exit 42', shell=True, env={u'hello':u'world'})"
vagrant@precise64:~$ python -c "import subprocess;subprocess.call('exit 42', shell=True, env={u'æ':u'æ'})")"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/lib/python2.7/subprocess.py", line 493, in call
    return Popen(*popenargs, **kwargs).wait()
  File "/usr/lib/python2.7/subprocess.py", line 679, in __init__
    errread, errwrite)
  File "/usr/lib/python2.7/subprocess.py", line 1249, in _execute_child
    raise child_exception
UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-1: ordinal not in range(128)
vagrant@precise64:~$

ionelmc · 2015-01-09T22:18:44Z

It's the _subprocess.CreateProcess call that is messing up. That, of course, is a winapi call, and not available on Linux for some tests.

Just as a reality check here... is it really supposed to be this difficult to get a two-character fix for an obvious bug into bumpversion?

I'd assume the maintainer doesn't have time to look closely and notice that this harmless change doesn't introduce any regressions (instead of just being plain rude and not explain that there is something very wrong with this change).

Anyway, so with few test fixes this almost pass on windows. The rest of the failures look minor and unrelated (line ending issues).

thebjorn · 2015-01-09T23:09:23Z

Sorry, got a little frustrated. Didn't mean to be so negative ;-)

My real goal is to get Subversion support in (https://github.com/datakortet/bumpversion/tree/subversion-support), but before that I need to get changes to the vcs abstractions in the test suite, and since that is going to be a bit of work I'd prefer to work on the platform I'm sitting on daily,... hence this fix first.

I am starting to wonder though, whether version bumping and vcs operations don't really belong in two separate tools...? (but that's neither here nor there).

peritus · 2015-01-10T10:29:23Z

Folks,

first, thank you for the time and interest in this little project of mine. I'm sorry for any frustrations that I may have caused :(

To re-iterate: I cannot reproduce this problem on linux -- ie. there is no way to write a regression test that will catch this on linux that I'm aware of. Not a single test in the testsuite passes before this fix on Windows (is that a regression test when the CI system doesn't run the tests on Windows..?)

Yes, I'm aware of that. I can't reproduce this on windows and at the moment there also is no continuous integration setup using a windows machine. I know the tests for 0.4 passed on windows (debugged that with a friend of mine on his windows machine), but apart from that I'm clueless for the state of windows support.

Just as a reality check here... is it really supposed to be this difficult to get a two-character fix for an obvious bug into bumpversion?

maintainer doesn't have time to look closely and notice that this harmless change doesn't introduce any regressions (instead of just being plain rude and not explain that there is something very wrong with this change).

Every bugfix I'm merging into this piece of software needs a regression test. Yes, I'm aware of that the change might not hurt execution in *nix environments, and not every test needs to have effect in all environments.

There's two options: I write the regression test myself or it comes as part of this or another pull request.

peritus · 2015-01-10T10:32:38Z

I am starting to wonder though, whether version bumping and vcs operations don't really belong in two separate tools...? (but that's neither here nor there).

Same here. Especially with changes in subversion being permanent (i.e. committed to the server) and without the possibility for rewriting history (like in git/hg).

I hope to address most of this once I get to implementing #38 — so one can choose to execute only the file changing part, or only the vcs part or do something in between. So maybe one tool but two different invocations :)

thebjorn · 2015-01-10T13:33:02Z

Hi Filip, I really would like to write a regression test, I just need some help figuring out what it should test..

Can we agree that these are Unicode strings (due to from __future__ import unicode_literals at the top of the file)? (note: this code was not present in v0.4)

[('HGENCODING', 'utf-8')]

my contention is that the reason this works on Linux is due to a bug in Python where it passes its Unicode buffer (internally encoded as utf-8?) directly to Linux' equivalent of CreateProcess. Since there are no code points above 127 in those strings, this (purely by accident) does not crash.

Python/Linux does not support putting Unicode directly into the environment as witnessed by the following command:

python -c "import subprocess;subprocess.call('exit 42', shell=True, env={u'æ':u'æ'})"

which on my linux machine produces:

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/lib/python2.7/subprocess.py", line 493, in call
    return Popen(*popenargs, **kwargs).wait()
  File "/usr/lib/python2.7/subprocess.py", line 679, in __init__
    errread, errwrite)
  File "/usr/lib/python2.7/subprocess.py", line 1249, in _execute_child
    raise child_exception
UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-1: ordinal not in range(128)
vagrant@precise64:~$

meaning that it is expecting ascii.

IOW, the env parameter is expecting a dict containing byte-strings and it is being passed two Unicode strings.

On Windows there is a type error regardless of the content of the Unicode strings (even empty strings cause a type error first):

(dev) go|c:\srv\bin\serverinit> python -c "import subprocess;subprocess.call('exit 42', shell=True, env={u'':u''})"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "c:\python27\Lib\subprocess.py", line 493, in call
    return Popen(*popenargs, **kwargs).wait()
  File "c:\python27\Lib\subprocess.py", line 679, in __init__
    errread, errwrite)
  File "c:\python27\Lib\subprocess.py", line 896, in _execute_child
    startupinfo)
TypeError: environment can only contain strings

This is the reason bumpversion as-is, currently does not run on Windows (and of course neither does the tests). I'm assuming the reason the tests ran in version 0.4 was because the offending code ([('HGENCODING', 'utf-8')]) did not exist in the code or the tests at that time.

Normally, when I think of regression tests, they are tests using the software and causing a failure before a fix and no failure after a fix. I hope I've convinced you that this is a real problem on Windows, yet there is no way (as far as I can see) to trigger this problem on Linux, at least not by writing a test that uses any of the code in bumpversion. Am I correct? If so, what would be an acceptable regression test for this change?

peritus · 2015-01-14T16:06:04Z

@thebjorn @ionelmc

Lets make this happen: I created a project for bumpversion on @appveyor and had my fair share of PowerShell config. Current state is "21 failed, 38 passed, 3 xfailed, 24 xpassed in 69.53 seconds" [https://ci.appveyor.com/project/peritus/bumpversion/build/18/job/vh6r93pcb4aj11ur] and that's mostly because I'm not able to configure mercurial non-interactively.

The appveyor branch also has this pull request merged in (thank you!) and that's what makes bumpversion work at all :)

I'll be fixing tests so that appveyor is 100% green, then squash-merge this into master.

thebjorn · 2015-01-14T19:41:40Z

Excellent news :-) Let me know if you need help with anything -- I'm not familiar with AppVeyor, but I know a little bit about developing on Windows.

ps: it looks like AppVeyor supports chocolatey (think apt-get for windows), which would make it easier to set up mercurial ("cinst hg"? based on: http://www.appveyor.com/docs/build-configuration#installing-software).

peritus · 2015-01-15T11:07:28Z

Using pip to install mercurial seems to work fine (on win32, win64 didn't like that), git seems to be pre-installed on the build image.

I cherry-picked your commit (w/o the test) to master, added an appveyor.yml config that explains how to do CI on windows. I also fixed the few obvious tests to depend less on a unix environment, so we're down to 6 failed, 78 passed, 2 xfailed in 76.52 seconds ..

As for the remaining tests: I'd definitely could use some help from someone more familiar with Python in a windows environment, especially since I don't want bumpversion to interfere with CR <-> CRLF conversions (sigh), so before I write "Windows support!" in the changelog I want to be sure it is doing the right thing (TM) — also maybe we can have some tests specifically for that ?

Thanks again for your persistence!

PS: Should I leave this open for you (now that your change is in master) ?
PPS: AFAIK Appveyor should also run for code in pull requests, but I haven't tried that yet.

ionelmc · 2015-01-15T11:14:11Z

FYI, I have this commit to fix some of the test issues ionelmc@63fea11

I think that brought it down to 2 failures on py27 env:

C:\Users\ionel_000\Projects\bumpversion>tox -e py27
GLOB sdist-make: C:\Users\ionel_000\Projects\bumpversion\setup.py
py27 inst-nodeps: C:\Users\ionel_000\Projects\bumpversion\.tox\dist\bumpversion-0.5.1.dev0.zip
py27 runtests: PYTHONHASHSEED='696'
py27 runtests: commands[0] | py.test tests.py
============================= test session starts =============================
platform win32 -- Python 2.7.9 -- py-1.4.26 -- pytest-2.6.4
collected 84 items

tests.py x.sX........X.....X.X..X.X.X.X.X.X..XXXX.XX.X.X.X.X.........X.X.X.X........F....FxX.

================================== FAILURES ===================================
___________________ test_search_replace_expanding_changelog ___________________
C:\Users\ionel_000\Projects\bumpversion\tests.py:1505: in test_search_replace_expanding_changelog
    assert postdate in tmpdir.join("CHANGELOG.md").read()
E   assert ')\n---------------------------\n\n* Some nice feature\n* Some other nice feature' in '\r\nMy awesome software project Changelog\r\n=====================================\r\n\r\nUnreleased\r\n----------\r\...15
)\n--------------------------- (2014-05-28)\r\n---------------------------\r\n\r\n* Another old nice feature\r\n\r\n'
E    +  where '\r\nMy awesome software project Changelog\r\n=====================================\r\n\r\nUnreleased\r\n----------\r\...15)\n--------------------------- (2014-05-28)\r\n---------------------------\r\n\r\n*
 Another old nice feature\r\n\r\n' = <bound method LocalPath.read of local(u'c:\\users\\ionel_~1\\appdata\\local\\temp\\pytest-19\\test_search_replace_expanding_0\\CHANGELOG.md')>()
E    +    where <bound method LocalPath.read of local(u'c:\\users\\ionel_~1\\appdata\\local\\temp\\pytest-19\\test_search_replace_expanding_0\\CHANGELOG.md')> = local(u'c:\\users\\ionel_~1\\appdata\\local\\temp\\pytest-1
9\\test_search_replace_expanding_0\\CHANGELOG.md').read
E    +      where local(u'c:\\users\\ionel_~1\\appdata\\local\\temp\\pytest-19\\test_search_replace_expanding_0\\CHANGELOG.md') = <bound method LocalPath.join of local('c:\\users\\ionel_~1\\appdata\\local\\temp\\pytest-1
9\\test_search_replace_expanding_0')>('CHANGELOG.md')
E    +        where <bound method LocalPath.join of local('c:\\users\\ionel_~1\\appdata\\local\\temp\\pytest-19\\test_search_replace_expanding_0')> = local('c:\\users\\ionel_~1\\appdata\\local\\temp\\pytest-19\\test_sear
ch_replace_expanding_0').join
---------------------------- Captured stdout call -----------------------------

My awesome software project Changelog
=====================================

Unreleased
----------

* Some nice feature
* Some other nice feature

Version v
Unreleased
----------
Version v8.2.0 (2015-01-15)
--------------------------- (2014-05-28)
---------------------------

* Another old nice feature


_______________________ test_multiline_search_is_found ________________________
C:\Users\ionel_000\Projects\bumpversion\tests.py:1628: in test_multiline_search_is_found
    main(['major'])
C:\Users\ionel_000\Projects\bumpversion\bumpversion\__init__.py:896: in main
    f.should_contain_version(current_version, context)
C:\Users\ionel_000\Projects\bumpversion\bumpversion\__init__.py:208: in should_contain_version
    assert self.contains(version.original), msg
E   AssertionError: Did not find '9.8.7' or '
E   A
E   B
E   C' in file the_alphabet.txt
=========================== short test summary info ===========================
XFAIL tests.py::test_unicode_env
  Windows does not allow Unicode in environment.
XFAIL tests.py::test_configparser_empty_lines_in_values
  configparser doesn't support empty_lines_in_values
FAIL tests.py::test_search_replace_expanding_changelog
FAIL tests.py::test_multiline_search_is_found
SKIP [1] C:\Users\ionel_000\Projects\bumpversion\.tox\py27\lib\site-packages\_pytest\skipping.py:142: This test doesn't make any sense anyway.
=== 2 failed, 54 passed, 1 skipped, 2 xfailed, 25 xpassed in 23.94 seconds ====
ERROR: InvocationError: 'C:\\Users\\ionel_000\\Projects\\bumpversion\\.tox\\py27\\Scripts\\py.test.EXE tests.py'
___________________________________ summary ___________________________________
ERROR:   py27: commands failed

peritus · 2015-01-15T11:29:34Z

@ionelmc Thanks for the pointer! I don't believe complicating the tests by allowing ConfigParsers stupid trailing whitespace (e.g. after serialize =, that needs a more general solution if that's a problem after all).

For % ("\r" if IS_WINDOWS else "") <- is that the right thing to do to not mess up code from teams using win and unix on the same project (regarding CR <-> CRLF)?

Could you have a look at the current master to see what works now ?

ionelmc · 2015-01-15T11:35:47Z

Ah yes, I'll take a look.

The test changes aren't very good (I'd be making a PR if they were any
good). About the "\r" thing - I suspect there is some minor bug somewhere
(inconsistent line endings) - you wouldn't want to have that.

Thanks,
-- Ionel Cristian Mărieș, blog.ionelmc.ro

On Thu, Jan 15, 2015 at 1:29 PM, Filip Noetzel notifications@github.com
wrote:

@ionelmc https://github.com/ionelmc Thanks for the pointer! I don't
believe complicating the tests by allowing ConfigParsers stupid trailing
whitespace (e.g. after serialize =, that needs a more general solution if
that's a problem after all).

For % ("\r" if IS_WINDOWS else "") <- is that the right thing to do to
not mess up code from teams using win and unix on the same project
(regarding CR <-> CRLF)?

Could you have a look at the current master to see what works now ?

—
Reply to this email directly or view it on GitHub
#64 (comment).

thebjorn · 2015-01-15T11:54:32Z

I get

tests.py FFF................................................................FF.......FF...Fx..
8 failed, 76 passed, 1 xfailed in 64.63 seconds

on a fresh checkout of master using py2.7.8.

For the line ending issue, I have the following fix (mode wb rather than wt):

    if not dry_run:
        # open/write mode should match the open/read mode above
        with io.open(self.path, 'wb') as f:
            f.write(file_content_after.encode('utf-8'))

the comment refers to opening the file at the beginning of def replace() with mode 'rb'.

It is correct to use wb in both places (it preserves the file's existing line endings -- which is preferred). Assuming the file is utf-8 is probably not always correct (but that doesn't effect line endings).

With the wb fix, 1 more test passes.

peritus · 2015-01-15T12:38:58Z

Thanks @thebjorn, I pushed that to master as e13d8d2 .. We're now down to 5 failed, 79 passed, 1 xfailed in 95.41 seconds (at least on appveyor's machine).

Do you know setuptools well enough to know why bumpversion is installed as bumpversion-script.py and if there is a way to change that ? I mean, I could fix the tests to be independent of bumpversion being invoked as bumpversion and document "Use bumpversion-script.py [options] if you're using windows", but if there was a way to have bumpversion or bumpversion.exe on windows, that would be more elegant.

ionelmc · 2015-01-15T12:43:00Z

bumpversion.exe is in fact created on windows, and in later versions of
setuptools is just a shim that calls bumpversion-script.py (thus the
incorrect name). Perhaps it's reasonable to just hardcode it as
"bumpversion" for all platforms?

Thanks,
-- Ionel Cristian Mărieș, blog.ionelmc.ro

On Thu, Jan 15, 2015 at 2:38 PM, Filip Noetzel notifications@github.com
wrote:

Thanks @thebjorn https://github.com/thebjorn, I pushed that to master
as e13d8d2
e13d8d2
.. We're now down to 5 failed, 79 passed, 1 xfailed in 95.41 seconds (at
least on appveyor's machine).

Do you know setuptools well enough to know why bumpversion is installed
as bumpversion-script.py and if there is a way to change that ? I mean, I
could fix the tests to be independent of bumpversion being invoked as
bumpversion and document "Use bumpversion-script.py [options] if you're
using windows", but if there was a way to have bumpversion or
bumpversion.exe on windows, that would be more elegant.

—
Reply to this email directly or view it on GitHub
#64 (comment).

thebjorn · 2015-01-15T16:45:06Z

The prog parameter to argparse.ArgumentParser() can be used to set the display name of the program. That will help the tests, and setuptools/distutils/.. have historically jumped through quite a few hoops so that windows users can just type the program name so it's probably safe to assume that will continue (as long as prog matches console_scripts in setup.py).

peritus · 2015-01-16T08:35:45Z

The prog parameter to argparse.ArgumentParser() can be used to set the display name

Didn't know that, thanks! Pushed that to master here: 41a5075

peritus · 2015-01-16T09:09:53Z

We're down to

2 failed, 82 passed, 1 xfailed in 109.36 seconds

(https://ci.appveyor.com/project/peritus/bumpversion/build/41/job/ithxdlw9ji0sq5qh)

.. and these seem to be the tricky/important ones.

thebjorn · 2015-01-16T11:56:27Z

If I print out the arguments in the first failing test I get (lhs):

u')\n---------------------------\n\n* Some nice feature\n* Some other nice feature'

and (rhs):

'\nMy awesome software project Changelog\n=====================================\n\nUnreleased\n----------\n\n* Some nice feature\n* Some other nice feature\n\nVersion v\nUnreleased\n----------\nVersion v8.2.0 (2015-01-16)\n--------------------------- (2014-05-28)\n---------------------------\n\n* Another old nice feature\n\n'

there is a unicode/byte-string mismatch that is probably benign. I haven't looked into the failure in any more detail (I'll have some time later today (CET) if you'd like me to take a look).

peritus · 2015-11-09T17:00:12Z

Closing this because I think the attached code doesn't fix the last few tests that are failing on appveyor (and thus are failing on windows :/ ).

If anyone wants to take a look at these, i'd really like to collaborate on making these work, but in another pull-request.

thebjorn added 2 commits December 18, 2014 19:24

Python 3x doesn't like explicit "unicode".

f4bce6e

Python 3x doesn't like explicit "unicode", relying on implicit unicode from `from __future__ import unicode_literals` instead.

peritus changed the title ~~Minimal fix for Unicode in environment problem on Windows.~~ Windows support Jan 14, 2015

This was referenced Jan 15, 2015

Fix line ending issue on windows. #70

Closed

.bumpversion.cfg:7: new blank line at EOF. #65

Open

peritus mentioned this pull request Jan 15, 2015

Git commit fails on Windows 7/8.1 with TypeError: environment can only contain strings #67

Closed

peritus mentioned this pull request Jun 26, 2015

Cannot execute tests if git is not installed #101

Open

peritus added the windows label Nov 9, 2015

peritus closed this Nov 9, 2015

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Windows support #64

Windows support #64

thebjorn commented Dec 18, 2014

ionelmc commented Dec 27, 2014

peritus commented Jan 9, 2015

ionelmc commented Jan 9, 2015

ionelmc commented Jan 9, 2015

thebjorn commented Jan 9, 2015

thebjorn commented Jan 9, 2015

thebjorn commented Jan 9, 2015

ionelmc commented Jan 9, 2015

thebjorn commented Jan 9, 2015

thebjorn commented Jan 9, 2015

thebjorn commented Jan 9, 2015

ionelmc commented Jan 9, 2015

thebjorn commented Jan 9, 2015

peritus commented Jan 10, 2015

peritus commented Jan 10, 2015

thebjorn commented Jan 10, 2015

peritus commented Jan 14, 2015

thebjorn commented Jan 14, 2015

peritus commented Jan 15, 2015

ionelmc commented Jan 15, 2015

peritus commented Jan 15, 2015

ionelmc commented Jan 15, 2015

thebjorn commented Jan 15, 2015

peritus commented Jan 15, 2015

ionelmc commented Jan 15, 2015

thebjorn commented Jan 15, 2015

peritus commented Jan 16, 2015

peritus commented Jan 16, 2015

thebjorn commented Jan 16, 2015

peritus commented Nov 9, 2015

Windows support #64

Windows support #64

Conversation

thebjorn commented Dec 18, 2014

ionelmc commented Dec 27, 2014

peritus commented Jan 9, 2015

ionelmc commented Jan 9, 2015

ionelmc commented Jan 9, 2015

thebjorn commented Jan 9, 2015

thebjorn commented Jan 9, 2015

thebjorn commented Jan 9, 2015

ionelmc commented Jan 9, 2015

thebjorn commented Jan 9, 2015

thebjorn commented Jan 9, 2015

thebjorn commented Jan 9, 2015

ionelmc commented Jan 9, 2015

thebjorn commented Jan 9, 2015

peritus commented Jan 10, 2015

peritus commented Jan 10, 2015

thebjorn commented Jan 10, 2015

peritus commented Jan 14, 2015

thebjorn commented Jan 14, 2015

peritus commented Jan 15, 2015

ionelmc commented Jan 15, 2015

peritus commented Jan 15, 2015

ionelmc commented Jan 15, 2015

thebjorn commented Jan 15, 2015

peritus commented Jan 15, 2015

ionelmc commented Jan 15, 2015

thebjorn commented Jan 15, 2015

peritus commented Jan 16, 2015

peritus commented Jan 16, 2015

thebjorn commented Jan 16, 2015

peritus commented Nov 9, 2015