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

Update CONTRIBUTING.md #161

Merged
merged 2 commits into from
Oct 30, 2021

Conversation

consideRatio
Copy link
Member

@consideRatio consideRatio commented Oct 29, 2021

I setup to do some local development but noted that the CONTRIBUTING.md section wasn't fully updated with the actual requirements for local development.

PR changes

  • CONTRIBUTING.md updated, it became a bit briefer by referencing the dev-jupyterhub_config.py instead
  • I added a dev-jupyterhub_config.py file to help quickly trial various of the configuration features.
  • I added a .flake8 config to avoid too strict linting with line length and to make exception for the c variable.

@consideRatio consideRatio changed the title Update contributing.md Update CONTRIBUTING.md Oct 29, 2021
@consideRatio consideRatio force-pushed the pr/update-contributing branch 2 times, most recently from 8cf7a0e to 76db608 Compare October 29, 2021 02:50
Copy link
Collaborator

@lambdaTotoro lambdaTotoro left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This all looks very good, but I have a few questions on particulars. See the comments for those. :)

.flake8 Outdated
# W: style warnings
# C: complexity
# F841: local variable assigned but never used
ignore = E, C, W, F841
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why are we chosing to ignore these now?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wanted to make the new dev-jupyterhub_python.py file not fail linting just because it included c, so that is why I added a .flake8 config at all. But, why did it now include ignore of the other things?

I opted to copy-paste a .flake8 config from another JupyterHub repo, in the organization we have often opted to have a relaxed flake8 configuration to not end ut being bothered by most non-failing things.

But, practically for this PR, I'm very happy to make it just to not bug us about c -- I'll remove the other opinionated changes in the flake8 config.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not opposed to this on principle. If it makes it more compatible / smooth within the organisation, that's a good reason to have it. I was just curious.
(I, for one, wouldn't mind a slightly longer maximum line length, I run into that a lot)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(I, for one, wouldn't mind a slightly longer maximum line length, I run into that a lot)

Oh I just ran into that as well and was a bit frustrated ^^

I'll let it be like this then, we typically have this to catch a few issues and then black to enforce formatting matters. We can do a pass on this kind of changes later, for now I'll make this as a minimal change as possible just introducing the builtin = c thing to avoid failures about the c variable from the traitlets library that makes it available when the the config file is parsed by an application.

dev-jupyterhub_config.py Show resolved Hide resolved
# c.NativeAuthenticator.recaptcha_secret = "your secret"

# import re
# c.NativeAuthenticator.allow_self_approval_for = re.compile('[^@]+@example\.com$')
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I actually recently identified a problem with this option.
This should just be the string and doesn't need the import of re. Compare commit 0861461.

dev-jupyterhub_config.py Show resolved Hide resolved
# -------------------------------------------------------------------------

c.NativeAuthenticator.check_common_password = False
c.NativeAuthenticator.minimum_password_length = 0
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we set these to 0 and 0 instead of something like 8 and 3?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I made it be the default value written out explicitly, but i can absolutely make it be 8 for example.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you think it might be prudent to change the defaults also? 🤔

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmmmm, well probably, but i'm not sure to what value to set. I know password hashes can be brute forced quite easily if its just a few characters in the password. I would be cautious about using something less than 8 if i wanted to ensure that a breached password hash list wouldn't make passwords reverse-engineered from the hashes.

But yeah I think its better to have a reasonable default, like 8, than to have it set to 0. At the same time, its a bit troubling to introduce a breaking change like this. I think I'd prefer to just leave it as it is and focus on documenting things about it for a informed decision by some admin.

@consideRatio
Copy link
Member Author

Thanks @lambdaTotoro for your review!

I'll get back to address things soon (< 24 hours I'm thinking)!

@lambdaTotoro
Copy link
Collaborator

Take your time! You're on a roll recently!

@consideRatio
Copy link
Member Author

Thanks for the quick review @lambdaTotoro! I've force pushed updated commits, just addressing the things discussed in the review comments.

@lambdaTotoro
Copy link
Collaborator

The new stuff looks good. Merging now. Thank you again for your valuable work! :)

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

Successfully merging this pull request may close these issues.

2 participants