Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make pkg defs Python 2/3 compatible #3850

Closed
wants to merge 2 commits into from

Conversation

treuherz
Copy link
Contributor

@treuherz treuherz commented Oct 2, 2017

Use BytesIO instead of StringIO, change strings to bytes throughout the
archiving code. Needed to import from Six in a couple of places.

As discussed in #1580

@bazel-io
Copy link
Member

bazel-io commented Oct 2, 2017

Can one of the admins verify this patch?

@treuherz
Copy link
Contributor Author

treuherz commented Oct 9, 2017

This will be able to be tested properly once #3873 is merged.

@hlopko hlopko requested a review from damienmg October 10, 2017 15:25
@hlopko hlopko added category: skylark > pkg build defs P3 We're not considering working on this, but happy to review a PR. (No assignee) type: feature request labels Oct 10, 2017
@damienmg
Copy link
Contributor

Jekins: test this please.

Thanks! I'll merge it if tests result are ok.

@bazel-io
Copy link
Member

Can one of the admins verify this patch?

@treuherz
Copy link
Contributor Author

Looks like a timeout in an (afaict) unrelated test. Is that one known to be flaky?

@damienmg
Copy link
Contributor

Sorry there was some reimaging going on, let's retry to get an answer from our CI:

retest this please

@treuherz
Copy link
Contributor Author

So the first of those checks is the same timeout as before. The second, most of the workspaces it's trying to build with are listed as missing. The third didn't fail when I submitted the request, but appears to be because the contents of //third_party/pprof aren't included in //third_party:srcs, which must have been introduced in 8e04f24

@damienmg
Copy link
Contributor

there is a problem: you can ignore everyone but bazel-tests but bazel-tests get cancelled all the time, let me retry (I deactivated the other ones): test this please

@treuherz
Copy link
Contributor Author

Appears to have again failed on the same tests as master. I don't think any of the CI is going to be able to test this fully until #3873 goes through, though, as the current config only makes sure it's compatible from the Python 2 side. Iif this is merged now, can I request that #3873 is rebuilt so I know I've not introduced any fun new failures?

@damienmg
Copy link
Contributor

damienmg commented Oct 11, 2017 via email

@damienmg
Copy link
Contributor

And this is breaking internally due to six imports... I need to take a closer look at it. Might take a bit longer.

@treuherz
Copy link
Contributor Author

Anything I can do to help here?

@damienmg
Copy link
Contributor

This requires weird change to third-party, I need to investigate more. Sorry for the delay

@treuherz
Copy link
Contributor Author

Sorry to keep nagging. Has there been any movement on this?

@damienmg damienmg requested review from philwo and removed request for damienmg December 14, 2017 14:14
@damienmg damienmg assigned philwo and unassigned damienmg Dec 14, 2017
@damienmg
Copy link
Contributor

Sorry I am leaving the Bazel team. This change require some non negligeable effort from the Bazel team to import. Reassigning to @philwo to opine

Use BytesIO instead of StringIO, change strings to bytes throughout the
archiving code. Needed to import from Six in a couple of places.
@treuherz
Copy link
Contributor Author

Have rebased against current master, and removed use of six, since that appeared to be a problem. Some of the updates to master since I did this have incorporated the same changes, so the diff's a bit smaller now, but master is still importing StringIO in py3-incompatible ways, and using it where it should be using BytesIO. @philwo Can I request a retest?

@duggelz
Copy link

duggelz commented Dec 21, 2017

Jekins: test this please

'\x60\x0a', # end of file entry
]
for i in inputs:
fileobj.write(i.encode())
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should explicitly specify the encoding as ascii or utf-8, instead of leaving it ambiguous. If we choose utf-8, then we have to encode first, then justify to 8 or 16 bytes. It looks like this is only called with ascii filenames, though.

@duggelz
Copy link

duggelz commented Dec 21, 2017

General comment for Bazel team - there is no unit test for make_deb.py, so breakages like this aren't caught, even by the Python-3-specific CI runs.

UTF-8 for tar, ASCII for ar, as appears to be the standard
@treuherz
Copy link
Contributor Author

treuherz commented Jan 2, 2018

That should be fixed. Don't think ar would know a two-byte character if it hit it in the face, so have stuck with Ascii for that one to be safe.

@duggelz
Copy link

duggelz commented Jan 10, 2018

Jenkins: test this please.

@bazel-io
Copy link
Member

Can one of the admins verify this patch?

@treuherz
Copy link
Contributor Author

Appears to have failed on something unrelated again, "test.xml.[failed-to-read]".

@duggelz
Copy link

duggelz commented Jan 11, 2018

Jenkins: test this please.

1 similar comment
@duggelz
Copy link

duggelz commented Jan 13, 2018

Jenkins: test this please.

@bazel-io bazel-io closed this in 6fff4da Jan 26, 2018
@duggelz
Copy link

duggelz commented Jan 26, 2018

Sorry for the delay, I was out sick for some time.

@treuherz
Copy link
Contributor Author

No worries, thanks for sorting this!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cla: yes P3 We're not considering working on this, but happy to review a PR. (No assignee) type: feature request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants