udim commented on a change in pull request #6707:
URL: https://github.com/apache/beam/pull/6707#discussion_r497754511
##########
File path:
buildSrc/src/main/groovy/org/apache/beam/gradle/BeamModulePlugin.groovy
##########
@@ -1492,5 +1492,79 @@ artifactId=${project.name}
dependsOn ':beam-sdks-java-container:docker'
}
}
+
+ /**
***********************************************************************************************/
+
+ project.ext.applyPythonNature = {
+
+ // Define common lifecycle tasks and artifact types
+ project.apply plugin: "base"
+
+ // For some reason base doesn't define a test task so we define it
below and make
+ // check depend on it. This makes the Python project similar to the task
layout like
+ // Java projects, see
https://docs.gradle.org/4.2.1/userguide/img/javaPluginTasks.png
+ project.task('test', type: Test) {}
+ project.check.dependsOn project.test
+
+
project.evaluationDependsOn(":beam-runners-google-cloud-dataflow-java-fn-api-worker")
+
+ project.ext.envdir = project.findProperty('envBaseDir') ?:
"${project.rootProject.buildDir}"
+ project.ext.envdir = project.ext.envdir + "/${project.name}/gradleenv"
Review comment:
Not sure if this is what you're encountering:
From what I recall of an investigation I did it boils down to the way
Python-based executables rely on the shebang line to run the python
interpreter. When such scripts are installed in a virtualenv, that line is
modified by setuptools to point to the virtualenv's interpreter and can easily
go over the limit (128?).
There was a workaround introduced in pip, setuptools, or virtualenv, but I
don't recall why it didn't apply to all the packages we depended on.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
