linkedin / pygradle

Using Gradle to build Python projects
https://github.com/linkedin/pygradle
Apache License 2.0
588 stars 147 forks source link

Version should be configurable in plugin #82

Open JLLeitschuh opened 7 years ago

JLLeitschuh commented 7 years ago

The plugin currently uses the hard coded project.version which may, in development enviroments, not be compliant with PEP-0440.

Additionally, in the java/maven world, -SNAPSHOT is used for versions while python uses .preview.

This problem exposes itself when you try to create an egg as I have done in #78. The egg for the version master_2016111701-SNAPSHOT has its version converted to master_2016111701_SNAPSHOT (notice the - character has become a _).

The result is that the egg has the name $project.name-$project.version.toString().replace("-", "_") which is very non-obvious.

The fix to this would be to put the project.version in the python plugin's properties but allow the user to override this value.

Example of location where version is hard coded

JLLeitschuh commented 7 years ago

I clearly don't understand gradle plugins. This works:

python {
    version = project.version.toString().replace("-SNAPSHOT", ".preview")
}
JLLeitschuh commented 7 years ago

So in order for the artifacts to also have the correct name you must have the python block declared above the imports of the python-sdist plugin.

apply plugin: 'com.linkedin.python'

def pythonVersion = project.version.toString().replace("-SNAPSHOT", ".preview")
// This must be declared above the application of the two plugins below.
python {
    version = pythonVersion
}

apply plugin: 'com.linkedin.python-sdist'

This is because the artifacts are added by these plugins using file names that contain the version. The artifact file name is not updated when the version number changes.

zvezdan commented 7 years ago

@JLLeitschuh Two questions:

  1. Did you try using ${ -> project.version } instead? That should resolve correctly after changes.
  2. Is there a reason why you use master_xxx instead of semantic versioning (e.g., 1.0.4)?

We do not have these issues because internally we always use a GradleDistribution class in setup.py (see our generated setup.py) that uses the python.pythonEnvironmentDistgradle to set the name and version from the project into the Python project correctly and we always use semantic versioning. We have some specific internal overrides, but the effect is as described.

We'll take a look at making this customizable, though, because I also noticed that one of the python build tools complains about deprecation of suffixes, such as -SNAPSHOT in the package version. Thanks for pointing this out.

JLLeitschuh commented 7 years ago

The versioning schema is something that the company uses internally for feature development and our master branch. We use semantic versioning for releases.

The problem is that the artifacts are generated when the plug-in is loaded.

The apply method for the plugin is not called again when the version is changed. You can see here that the method that declares the artifact's location is here: https://github.com/linkedin/pygradle/blob/master/pygradle-plugin/src/main/groovy/com/linkedin/gradle/python/plugin/PythonSourceDistributionPlugin.groovy#L40

This is the method that is called: https://github.com/linkedin/pygradle/blob/master/pygradle-plugin/src/main/groovy/com/linkedin/gradle/python/tasks/SourceDistTask.java#L58

So really, the file's location is what needs to be lazily evaluated in the plugins code.