GPflow: GPflow python package name doesn't follow PEP8
Hello everyone,
According to PEP8 - packages and modules should have short and lowercase names. The irony is that contribution markdown file tells that GPflow code should follow PEP8. But it’s not too late to change, as GPflow is not present on public pip/anaconda repositories yet and version is below 1.0.0.
The transition can be done in three primitive phases:
- Inform people that current version will be deprecated and replaced with new one on XX/XX/2017. (Warn of deprecation in Readme file or issue on Github).
- Provide a script which updates the code with GPflow.
#!/bin/bash
PROJECT=$1
find "${PROJECT}" -type f -exec sed -i -e 's/GPflow\./gpflow./g' {} \;
find "${PROJECT}" -type f -exec sed -i -e 's/^import GPflow/import gpflow/g' {} \;
find "${PROJECT}" -type f -exec sed -i -e 's/^from GPflow/from gpflow/g' {} \;
- Merge PR into the master.
I have created #451, where I renamed only code/module/package related stuff. The documentation, citings and docstrings refer to GPflow name as before.
About this issue
- Original URL
- State: closed
- Created 7 years ago
- Comments: 15 (15 by maintainers)
On the basis of the discussion, I’m leaning toward changing, but I think we should also canvas the opinions of @javdrher and @icouckuy given the work they have done on GPflowOpt before we do anything.
I have a mild preference for gpflow, since that follows the pep8 standard.
To be clear, I think the project should be called GPflow (github.com/GPflow/…), but the package should be gpflow. This might initially sound problematic, but after consideration I think it’s quite a clean solution. The paper gets to remain the same, but we’re standards compliant with pep8.
Small request: could the version number of GPflow increase with this merge, and the merge commit get tagged as release on github? GPflowOpt will then depend on that release instead of master (which makes sense for compatibility)