1.0.2: ValueError: I/O operation on closed file

[yarikoptic]

Just a quick report that I think I am observing this new behavior after upgrade (from e.g. 1.0.1+git137-gc8b8379) of GitPython to 1.0.2 on OSX and Linux:

  File "/home/yoh/proj/datalad/datalad/venv-tests/local/lib/python2.7/site-packages/git/repo/base.py", line 885, in clone_from
    return cls._clone(git, url, to_path, GitCmdObjectDB, progress, **kwargs)
  File "/home/yoh/proj/datalad/datalad/venv-tests/local/lib/python2.7/site-packages/git/repo/base.py", line 831, in _clone
    finalize_process(proc)
  File "/home/yoh/proj/datalad/datalad/venv-tests/local/lib/python2.7/site-packages/git/util.py", line 155, in finalize_process
    proc.wait()
  File "/home/yoh/proj/datalad/datalad/venv-tests/local/lib/python2.7/site-packages/git/cmd.py", line 319, in wait
    raise GitCommandError(self.args, status, self.proc.stderr.read())
ValueError: I/O operation on closed file

anything obvious comes to mind?

[yarikoptic]

ok - in my case it happens because existing repository already exists, so git clone fails and I was expecting to swallow GitCommandError exception, but got ValueError due to attempt to read stderr

[yarikoptic]

yeap:

2 11049.....................................:Fri 12 Feb 2016 01:07:01 PM EST:.
(git)hopa:~deb/python-git[remotes/upstream/master]git
$> python -c 'import git; git.Repo.clone_from("git://github.com/gitpython-developers/GitPython", "/tmp/gitp")'
2 11050.....................................:Fri 12 Feb 2016 01:07:04 PM EST:.
(git)hopa:~deb/python-git[remotes/upstream/master]git
$> python -c 'import git; git.Repo.clone_from("git://github.com/gitpython-developers/GitPython", "/tmp/gitp")'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "git/repo/base.py", line 885, in clone_from
    return cls._clone(git, url, to_path, GitCmdObjectDB, progress, **kwargs)
  File "git/repo/base.py", line 831, in _clone
    finalize_process(proc)
  File "git/util.py", line 155, in finalize_process
    proc.wait()
  File "git/cmd.py", line 319, in wait
    raise GitCommandError(self.args, status, self.proc.stderr.read())
ValueError: I/O operation on closed file

quick bisect lead to b145de3 where it was introduced

[yarikoptic]

Thanks. Since no due date for 1.0.3 any idea when? ;-)

[Byron]

'When it's worth it'™, or when a critical fix comes up. The first mentioned rule of thumb probably isn't too helpful, but that's how it was handled so far and thus rather accurately describes the status quo.
I am open to suggestions, a release now takes me about 10 minutes, and makes me dislike python just a little more :) !

[yarikoptic]

10 min is indeed nice and short.. Usually it takes me longer with my projects since I also build/upload Debian packages etc. But for https://github.com/duecredit/duecredit at least as far as pypi goes and me not carrying about changelog yet, automated fully, so I just need to push commit with a release tag. Version string, pypi, everything is automatic.
Is asking because in this case I would need to either relax our test which fails due to this issue, or wait for the release (since I don't want to restrict versions etc)

[Byron]

Thanks for sharing ! My setup isn't automated at all, so I have to suffer through that pypi web-site all the time. I know there is an auto-upload/publish feature, but last time I checked it wanted my credentials in clear-text on disk somewhere. Probably I have just abandoned the entire python package infrastructure, so all that's left in me is strongly disliking every bit of it.

That said, I'd rather not get into the habit of adjusting my previous rules of thumb.
Is it possible for you to refer to individual commits, and fetch gitpython from GitHub directly ? I know that pip can do that.

[yarikoptic]

ok -- I Can point for now back to master ... but then additional regression crept in -- stderr is no longer proxied to the user, so error message is just a cryptic exit code... Compare:

$> python -c 'import git; from nose.tools import assert_raises; git.Repo.clone_from("git://github.com/gitpython-developers/GitPython", "/tmp/gitp")'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/home/yoh/proj/datalad/datalad/venv-tests/local/lib/python2.7/site-packages/git/repo/base.py", line 885, in clone_from
    return cls._clone(git, url, to_path, GitCmdObjectDB, progress, **kwargs)
  File "/home/yoh/proj/datalad/datalad/venv-tests/local/lib/python2.7/site-packages/git/repo/base.py", line 831, in _clone
    finalize_process(proc)
  File "/home/yoh/proj/datalad/datalad/venv-tests/local/lib/python2.7/site-packages/git/util.py", line 155, in finalize_process
    proc.wait()
  File "/home/yoh/proj/datalad/datalad/venv-tests/local/lib/python2.7/site-packages/git/cmd.py", line 327, in wait
    raise GitCommandError(self.args, status, errstr)
git.exc.GitCommandError: 'git clone -v git://github.com/gitpython-developers/GitPython /tmp/gitp' returned with exit code 128

to previous version

$> /usr/bin/python -c 'import git; from nose.tools import assert_raises; git.Repo.clone_from("git://github.com/gitpython-developers/GitPython", "/tmp/gitp")' 
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/lib/python2.7/dist-packages/git/repo/base.py", line 887, in clone_from
    return cls._clone(git, url, to_path, GitCmdObjectDB, progress, **kwargs)
  File "/usr/lib/python2.7/dist-packages/git/repo/base.py", line 833, in _clone
    finalize_process(proc)
  File "/usr/lib/python2.7/dist-packages/git/util.py", line 155, in finalize_process
    proc.wait()
  File "/usr/lib/python2.7/dist-packages/git/cmd.py", line 315, in wait
    raise GitCommandError(self.args, status, self.proc.stderr.read())
git.exc.GitCommandError: 'git clone -v git://github.com/gitpython-developers/GitPython /tmp/gitp' returned with exit code 128
stderr: 'fatal: destination path '/tmp/gitp' already exists and is not an empty directory.
'

[yarikoptic]

So imho either GitCommandError msg should be improved or stderr came back ;) exit_code's are for computers and sysadmins, not for humans ;-)

[Byron]

Good catch ! This should be fixed now.

[tomriddle1234]

I'm a new user of GitPython, and now first issue I 'm having is this, wish it can be fixed asap

[Byron]

@tomriddle1234 Have you tried it with the latest master ? The fix has already landed, but is not yet released on pypi.