I think https://github.com/apache/beam/pull/13308 is about ready to merge. One question was whether or not to install pyenv in the container - I think we should try to do without it. Users of this environment will already be operating within a container, so they shouldn't need pyenv to create isolated python environments, they could just use the container's system python.
The two issues Alex mentioned are still outstanding, but they seem to be issues with ./gradlew check unrelated to the container. I filed BEAM-11402 [1] to track this separately. [1] https://issues.apache.org/jira/browse/BEAM-11402 On Mon, Nov 30, 2020 at 11:43 AM Alex Amato <ajam...@google.com> wrote: > If any of these are suitable for at least some development. I propose we > merge them, and update them with fixes later. Rather than trying to get > things 100% working in the first PR. > > Looks like this one was opened in early Sept, and never got merged. Which > is a pretty long time. Perhaps abandoned for the later? > https://github.com/apache/beam/pull/12837 > > This one looks like its just failing on just a few tests (Which may be > addressed soon, but the PR was opened 19 days ago). > https://github.com/apache/beam/pull/13308 > (Can we set a deadline for this? And just say merge it by the end of the > week, regardless if the last two tests can be fixed or not?) > > (Would like to nudge this along, as it's been a pain point for many for a > while now). > > Thanks for the work here Niels, Omar and Sam. > Looking forward to giving this a try :) > > > On Mon, Nov 30, 2020 at 11:32 AM Brian Hulette <bhule...@google.com> > wrote: > >> I agree this is a good idea. I remember my first experience with Beam >> development - I ran through the steps at [1] and had `./gradlew check` >> fail. I don't think I ever got it working before moving on and just running >> more specific tasks. >> It would be great if we had a reliable way for new contributors to >> establish an environment that can successfully run `./gradlew check`. >> >> Niels Basjes' PR (https://github.com/apache/beam/pull/13308) seems to be >> close to that, so I think we should focus on getting that working and >> iterate from there. Omar concurred with that in >> https://github.com/apache/beam/pull/12837. >> >> [1] https://beam.apache.org/contribute/#development-setup >> >> >> On Wed, Nov 25, 2020 at 3:39 PM Ahmet Altay <al...@google.com> wrote: >> >>> Thank you for doing this. >>> >>> I have seen a few related PRs. Connecting them here in case these >>> efforts could be combined: >>> - https://github.com/apache/beam/pull/12837 (/cc +Omar Ismail >>> <omarism...@google.com> ) >>> - https://github.com/apache/beam/pull/13308 >>> >>> Ahmet >>> >>> On Wed, Nov 25, 2020 at 2:53 PM Sam Rohde <sro...@google.com> wrote: >>> >>>> Hi All, >>>> >>>> I got tired of my local dev environment being ruined by updates so I >>>> made a container for Apache Beam development work. What this does is create >>>> a Docker container from the Ubuntu Groovy image and load it up with all the >>>> necessary libraries/utilities for Apache Beam development. Then I run an >>>> interactive shell in the Docker container where I do my work. >>>> >>>> This is a nice way for new contributors to easily get started. However >>>> with the container in its current form, I don't know if this will help >>>> other people because it is tied closely with my workflow (using VIM, >>>> YouCompleteMe, for Python). But I think it can be a nice starting point for >>>> improvements. For example: >>>> >>>> - Sharing the host display with Docker to start GUI applications >>>> (like IntelliJ) in the container >>>> - Adding Golang development support >>>> >>>> Here's a draft PR <https://github.com/apache/beam/pull/13430>, let me >>>> know what you think, how it can be improved, and whether it's a good idea >>>> for us to have a dev container like this. >>>> >>>> Regards, >>>> Sam >>>> >>>>
