In that case (and just to confirm this is the problem), can you run faber by using
python3 path/to/faber/script instead ?
Do you mind submitting a bug report to https://github.com/stefanseefeld/faber/issues ?
I am interested in contributing to boost-python, any pointers on how to get going?
Hi everyone, I'm Nirmal, a CS undergraduate student from IIIT Hyderabad, India. I would like to work with boostc++ for this year's GSoC. I want to connect with this community to know more about this org. But, many of the boostorg's chat rooms are not accessible. So can someone please tell me the chat room I should join be joining in case this is not the right one? Asking because this seems like a sub-room for detailed discussions.
So it sounds like travis-ci.org is going to get a lot more restricted for open source projects. Any thoughts on migrating python's CI? Github Actions?
What do you think of the pull request that does the 8 linux configurati
ons? I was thinking it would be best to get the easiest ones going first.
Another (more specific) question is: looking at https://github.com/boostorg/python/pull/335/files#diff-1a8cf21570cf96acf7408fd6572a61a36aae89cb22dd3563de3b936f9e89bcb8 I wonder how you install
faber. Is this already included in your docker image ?
Yes, both the gcc and clang image get faber, as well as the BCP'ed part of the tree for python dependencies.
I don't believe there is anything you need to do to enable them, but I could be wrong. I didn't have to do anything for my forked repo. Testing the PR is more difficult. Might be easiest to bring that one file in on your own branch in the boostorg/python repo. This, being an infrastructure change, is a bit different than a normal code change.
As soon as all this is working, I'll move on to Boost.Python. I expect to complete this before the end of the year.
@teeks99 , do you have experience with OSX ? I have set up a workflow (for faber only, for now) for Ubuntu, Windows, and OSX, but the latter produces link errors: https://github.com/stefanseefeld/faber/runs/1583570864?check_suite_focus=true
I wonder whether I missed anything in the Python setup...
Faber migration to github actions is complete (https://github.com/stefanseefeld/faber/actions), now on to Boost.Python. :-)
I have a few comments on boostorg/python#335, and as we are here, perhaps it's easier to do this live...
Can you squash all commits into one, but leave out the change to the appveyor config ? That way the PR will be a single commit, adding a single file. Also, as you said yourself, the
1.66 release is rather old, so perhaps this would be an opportunity to move to a more recent boost release as baseline ? (only if this is easy and quick to do)
Otherwise this looks great, and I'm really thankful for your help with this.
(I would actually like to clone this workflow as soon as it's committed to run OSX and Windows builds. Once that's done, we can decommission travis-ci as well as appveyor.)
Is there not an option in the pull request to squash the commits? If not, you may need to turn that on for the repo.
I wanted to get things working first, then I'll put out another pull request to move to 1.75. Also, I'm still having a small issue getting 1.75 to BCP correctly in my docker image, so I want to get to the bottom of that.
OSX and Windows will look a lot different. I don't believe there is any way to run docker images with OSX, so we'll need to do all of that setup logic in boost::python's workflow. As I mentioned in the boostorg/python#334 issue, I've got a branch started with Mac OSX support, but I'm having serious problems with it. You want to have a look and see if you have any ideas?
For windows, docker images are supported, but the environment isn't quite as settled as docker on linux. I do have a VS2019 docker image (src), but it isn't quite ready for prime time...and I don't have any older versions dockerized yet. I'd vote that we stick with the windows image from github for now. Plus Appveyor is still working fairly well, so this isn't quite as urgent.
On that note, the appveyor scripts are tied to exact version numbers of visual studio...which was breaking when the appveyor people updated their image. Is there a way to only specify the major version of visual studio (or the msvc toolset, i.e. 14.0, 14.1, 14.2)? I'm not familiar with fabers toolset lookup options.
There is a very simple pull request for appveyor waiting out there that simply rolls the VS2019 version from 16.8.1 to 16.8.3....but that's a losing battle. We'd need to update every few weeks.
Hi Tom, sorry I just now saw your messages. Yes, there is an interface at github for squashing. But I really want to exclude the change to the
.travis.yml file, to keep things separate. So if you can remove that commit from the PR, we can merge it (with squashing). Moving to 1.75 in a second PR is perfectly fine. There will be a couple of iterations until we get the full coverage (including OSX) that travis-ci now provides.
I'm a bit confused about docker images for windows, as I didn't think docker would run there. (I do know that you can run docker in sort of a Linux VM running on top of Windows, which looks like docker on Windows. But as the goal is to test with MSVC, docker wouldn't be of any help.
Either way, I do know that
Either way, I do know that
runs-on: windows-latest is supported, no matter how that's implemented. :-)