search

PyCQA / flake8-import-order

Flake8 plugin that checks import order against various Python Style Guides
GNU Lesser General Public License v3.0
278 stars 72 forks source link

Add support for --application-package-names option #88

Closed jhuttner closed 8 years ago

jhuttner commented 8 years ago

The --application-package-names flag allows for code which is owned by the developer's company, but which is not local to the curent repository or codebase, to be ranked higher in import order checking than local imports, but lower than third-party imports.

jhuttner commented 8 years ago

Hello @pgjones, I do not think this build error is a result of my changes. Can you advise me on how you would like me to proceed? Thank you.

pgjones commented 8 years ago

No I don't thin the build is related and I'll sort out the build issues.

Could you explain the motivation for a distinction in the third party imports between 'local' and remote? (Which I think is what this achieves). Could you also explain how you see this distinction being applied (or not) to the various styles this projects support? Finally I am struggling to see this as being a generic addition that is not specific for your workflow, could you explain why you (presumably) think it isn't?

jhuttner commented 8 years ago

Hi Phil,

Sure, happy to try to answer your questions.

Could you explain the motivation for a distinction in the third party imports between 'local' and remote?

The motivation is so that those reading the code know what packages are provided by the author's company or organization, and which are provided by the broader community. In grouping these imports together, as flake8-import-order currently does, this distinction cannot be discerned. Since the process for changing an internal package is often much easier and attainable than, say, changing the argument order in a function in a popular third-party package, flagging this distinction by visually separating the import blocks is helpful.

Could you also explain how you see this distinction being applied (or not) to the various styles this projects support?

All the styles accommodate this change if the application-package-names value is set. The module would simply throw an error when local packages are imported before third-party packages. In not setting the flag, there is no difference in the linting result.

Finally I am struggling to see this as being a generic addition that is not specific for your workflow, could you explain why you (presumably) think it isn't?

Many companies use internal PyPi or DevPi servers to distribute internally-written, proprietary Python packages for use by their own Python applications in production. Still others distribute these packages using Yum, Apt, or other OS-level package managers. Since the code contained in these packages is not a relative import, its import line should not be grouped with the relative imports. But, as stated earlier, these are not truly third-party imports since the code belongs to the company or organization. Thus, a new import section is needed.

pgjones commented 8 years ago

I'm not sure all the styles can accommodate this change, as the PEP8, cryptography, google and Smarkets style guides make no mention of a third party distinction and I'm not sure adding one would be compliant. This is what leads me to conclude it this is a new specific style, rather than an additional flag for all styles.

Do you want to propose this as a new flake8-import-order style?

jhuttner commented 8 years ago

Good point, I agree.

Sure, I've created a pull request for a new appnexus style here: https://github.com/PyCQA/flake8-import-order/pull/90