Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Removing import in __init__.py #169

Closed
jordan-bonecutter opened this issue Oct 11, 2022 · 7 comments · Fixed by #170
Closed

Removing import in __init__.py #169

jordan-bonecutter opened this issue Oct 11, 2022 · 7 comments · Fixed by #170
Labels

Comments

@jordan-bonecutter
Copy link

I have a python package with a structure like:

.
├── setup.py
└── mypackage
    ├── __init__.py
    └── mypackage.py

The contents of __init__.py are as follows:

from .mypackage import *

Autoflake is removing all contents from __init__.py breaking the package install. To fix the issue I'm asking autoflake to ignore __init__.py

@fsouza
Copy link
Collaborator

fsouza commented Oct 11, 2022

We can't have autoflake ignore init.py everywhere, as not everyone follows the same conventions. You have some options here:

  1. add a # noqa comment to that line
  2. invoke autoflake with --exclude=__init__.py

@jordan-bonecutter
Copy link
Author

We can't have autoflake ignore init.py everywhere, as not everyone follows the same conventions. You have some options here:

  1. add a # noqa comment to that line
  2. invoke autoflake with --exclude=__init__.py

I have done that, though this is new behavior in 1.7.3. Reverting back to 1.7.0 leaves my import untouched. This seems like a breaking import removal IMO and autoflake shouldn't touch it (it broke my code at the very least, I imagine I'm not alone here)

@fsouza
Copy link
Collaborator

fsouza commented Oct 11, 2022

We can't have autoflake ignore init.py everywhere, as not everyone follows the same conventions. You have some options here:

  1. add a # noqa comment to that line
  2. invoke autoflake with --exclude=__init__.py

I have done that, though this is new behavior in 1.7.3. Reverting back to 1.7.0 leaves my import untouched. This seems like a breaking import removal IMO and autoflake shouldn't touch it (it broke my code at the very least, I imagine I'm not alone here)

Are you saying that --exclude didn't work? 🤔 Or that you didn't need --exclude before?

@jordan-bonecutter
Copy link
Author

We can't have autoflake ignore init.py everywhere, as not everyone follows the same conventions. You have some options here:

  1. add a # noqa comment to that line
  2. invoke autoflake with --exclude=__init__.py

I have done that, though this is new behavior in 1.7.3. Reverting back to 1.7.0 leaves my import untouched. This seems like a breaking import removal IMO and autoflake shouldn't touch it (it broke my code at the very least, I imagine I'm not alone here)

Are you saying that --exclude didn't work? thinking Or that you didn't need --exclude before?

My bad, should have been more specific. --exclude works but I didn't need it before 1.7.3 for this specific file. I assume this is a new feature

@fsouza
Copy link
Collaborator

fsouza commented Oct 11, 2022

My bad, should have been more specific. --exclude works but I didn't need it before 1.7.3 for this specific file. I assume this is a new feature

Gotcha, thanks for clarifying! Sounds like a regression then, it was definitely not intended. I'll investigate it.

@fsouza fsouza added the bug label Oct 11, 2022
@urtubia
Copy link

urtubia commented Oct 12, 2022

Hello!
I'm running into a similar issue and I think this unittest shows the problem (I tested by including this test on test_autoflake.py)

  def test_end_to_end_dont_remove_unused_imports_when_not_using_flag(self):
        with temporary_file(
            """\
from . import fake_bar
from . import fake_foo
fake_foo.fake_function()
""",
        ) as filename:
            process = subprocess.Popen(
                AUTOFLAKE_COMMAND
                + [
                    filename,
                ],
                stdout=subprocess.PIPE,
            )
            self.assertEqual(
                "",
                "\n".join(process.communicate()[0].decode().split(os.linesep)[3:]),
            )

I ran this test on different release labels and I noticed that it passed on v1.7.1 and started failing on v1.7.2

@fsouza
Copy link
Collaborator

fsouza commented Oct 12, 2022

@urtubia thanks for sharing the reproducer. I see what's going on now. Fix coming soon.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants