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

Clean up work on constants. #6919

Merged
merged 15 commits into from
Jun 17, 2019
Merged

Clean up work on constants. #6919

merged 15 commits into from
Jun 17, 2019

Conversation

YashJipkate
Copy link
Contributor

Explanation

This PR is a clone of #6915.

Checklist

  • The PR title starts with "Fix #bugnum: ", followed by a short, clear summary of the changes. (If this PR fixes part of an issue, prefix the title with "Fix part of #bugnum: ...".)
  • The PR explanation includes the words "Fixes #bugnum: ..." (or "Fixes part of #bugnum" if the PR only partially fixes an issue).
  • The linter/Karma presubmit checks have passed.
    • These should run automatically, but if not, you can manually trigger them locally using python scripts/pre_commit_linter.py and bash scripts/run_frontend_tests.sh.
  • The PR is made from a branch that's not called "develop".
  • The PR has an appropriate "CHANGELOG: ..." label (If you are unsure of which label to add, ask the reviewers for guidance).
  • The PR follows the style guide.
  • The PR addresses the points mentioned in the codeowner checks for the files/folders changed. (See the codeowner's wiki page.)
  • The PR is assigned to an appropriate reviewer.
    • If you're a new contributor, please ask on Gitter for someone to assign a reviewer and don't tick this checkbox.
    • If you're not sure who the appropriate reviewer is, please assign to the issue's "owner" -- see the "talk-to" label on the issue. Do not only request the review but also add the reviewer as an assignee.

Copy link
Contributor

@vinitamurthi vinitamurthi left a comment

Choose a reason for hiding this comment

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

Approving for question-player and practice-session files

@YashJipkate
Copy link
Contributor Author

@seanlip @kevinlee12 The setup test shows pending here while it has passed as I saw in the dashboard:
Screenshot from 2019-06-14 07-40-29

Also, the frontend and backend tests are passing which implies that the setup test must have passed.

Copy link
Contributor

@kevinlee12 kevinlee12 left a comment

Choose a reason for hiding this comment

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

lgtm!

I think we can probably override it since this is because Github isn't reporting the correct status.

@seanlip
Copy link
Member

seanlip commented Jun 14, 2019 via email

@seanlip
Copy link
Member

seanlip commented Jun 14, 2019

Oh, that said, I am not too concerned about "setup" if the others do pass. (I made the original response via email.)

/cc @oppia/dev-workflow-team any idea why this is happening?

@YashJipkate
Copy link
Contributor Author

@seanlip The other tests do pass! Could this be merged then?

Copy link
Member

@seanlip seanlip left a comment

Choose a reason for hiding this comment

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

Hi @YashJipkate, took a pass, and I have a question. I think each constant should be declared exactly once in all of Oppia. I'm fine having a policy of "if a constant is used more than once, put it at app level", though there may be other better ways of handling this.

What are the policies that you would like to put in place, in order to achieve this? I would also like the presubmit checks that force this policy to be followed in the future to be part of this PR, so that devs don't (accidentally) undo the work you've done to separate them properly.

@seanlip
Copy link
Member

seanlip commented Jun 14, 2019

@vojtechjelinek @Jamesjay4199 Flagging this comment, PTAL.

@YashJipkate YashJipkate requested a review from brianrodri as a code owner June 14, 2019 12:08
@YashJipkate
Copy link
Contributor Author

@YashJipkate did you see this comment? #6919 (comment)

I have already addressed that comment, Sorry for not saying the same on the thread.

but I am not going to approve this until the INTERACTION_SPECS constant appears in only one place.

I thought that you meant this was something @Jamesjay4199 would have as a TODO. MIght be some misunderstanding of mine.
I have made a new file which has the constant and imported it wherever needed. PTAL!

@YashJipkate YashJipkate requested a review from seanlip June 16, 2019 07:57
@@ -314,6 +314,8 @@
/core/jobs*.py @seanlip
/core/platform/ @seanlip
/core/templates/dev/head/App*.ts @ankita240796
/core/templates/dev/head/app.constants.ts @ankita240796
/core/templates/dev/head/pages/interaction-specs.contants.ts @ankita240796
Copy link
Contributor Author

Choose a reason for hiding this comment

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

@seanlip I am not sure about this. Could you confirm?

Copy link
Member

Choose a reason for hiding this comment

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

I would say @vojtechjelinek (what do you think, @vojtechjelinek)?

@seanlip
Copy link
Member

seanlip commented Jun 16, 2019

I have already addressed that comment, Sorry for not saying the same on the thread.

But shouldn't that check have caught the case of INTERACTION_SPECS being repeated in the codebase, if it was working correctly?

@YashJipkate
Copy link
Contributor Author

@seanlip The tests now pass (on my local). PTAL!

@YashJipkate
Copy link
Contributor Author

But shouldn't that check have caught the case of interaction-specs being repeated in the codebase, if it was working correctly?

I had an exception for INTERACTION_SPECS in the linter so it is exempted.

@@ -314,6 +314,8 @@
/core/jobs*.py @seanlip
/core/platform/ @seanlip
/core/templates/dev/head/App*.ts @ankita240796
/core/templates/dev/head/app.constants.ts @ankita240796
/core/templates/dev/head/pages/interaction-specs.contants.ts @ankita240796
Copy link
Member

Choose a reason for hiding this comment

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

I would say @vojtechjelinek (what do you think, @vojtechjelinek)?

@@ -347,6 +347,15 @@
'/scripts/install_third_party.sh',
'/.github/']

OLD_CONVENTION_DIRECTORIES = [
'core/templates/dev/head/services',
'core/templates/dev/head/base_components',
Copy link
Member

Choose a reason for hiding this comment

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

Isn't this new? It wasn't around in the "old" codebase...

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I don't think I understood you completely. These are the directories which follow the old convention and hence the name.

Copy link
Member

Choose a reason for hiding this comment

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

I guess I was thinking that base_components seems to have been recently added and is here to stay? I thought the idea was that all "new" dirs are cleaned up and we were going to remove all the dirs in this list completely over time... (which, btw, merits an issue or a TODO).

Are we planning to delete base_components too?

Copy link
Contributor Author

@YashJipkate YashJipkate Jun 16, 2019

Choose a reason for hiding this comment

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

No, it doesn't need to be deleted. It just means that it is following the old convention. When we will empty this list out, it would mean that these directories now follow the new convention.

Copy link
Member

Choose a reason for hiding this comment

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

OK. I think you missed adding both an issue and a TODO for this (see previous comment). We need some way of keeping track of the task of "making this list empty".

Also add a comment above line 350 to explain to new devs what this constant is (in particular what is meant by "old convention").

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I have added a comment as well a TODO. PTAL.

scripts/pre_commit_linter.py Show resolved Hide resolved
scripts/pre_commit_linter.py Show resolved Hide resolved
scripts/pre_commit_linter.py Outdated Show resolved Hide resolved
scripts/pre_commit_linter.py Outdated Show resolved Hide resolved
scripts/pre_commit_linter.py Outdated Show resolved Hide resolved
@YashJipkate YashJipkate reopened this Jun 16, 2019
@oppiabot
Copy link

oppiabot bot commented Jun 16, 2019

Hi @YashJipkate. Due to recent changes in the "develop" branch, this PR now has a merge conflict. Please follow this link if you need help resolving the conflict, so that the PR can be merged. Thanks!

Copy link
Member

@seanlip seanlip left a comment

Choose a reason for hiding this comment

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

Basically LGTM. Thanks @YashJipkate!

Is this PR blocking future work? If so, then if Travis tests pass you are welcome to incorporate the changes from here in the next PR instead, so that we can get this in.

.github/CODEOWNERS Outdated Show resolved Hide resolved
@@ -347,6 +347,15 @@
'/scripts/install_third_party.sh',
'/.github/']

OLD_CONVENTION_DIRECTORIES = [
'core/templates/dev/head/services',
'core/templates/dev/head/base_components',
Copy link
Member

Choose a reason for hiding this comment

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

OK. I think you missed adding both an issue and a TODO for this (see previous comment). We need some way of keeping track of the task of "making this list empty".

Also add a comment above line 350 to explain to new devs what this constant is (in particular what is meant by "old convention").

core/templates/dev/head/app.constants.ts Show resolved Hide resolved
scripts/pre_commit_linter.py Show resolved Hide resolved
@YashJipkate
Copy link
Contributor Author

Hi @seanlip. No, this is not blocking any of my work currently (the one actually blocking is #6939) since work on Angular migration on constants can only begin after hybridization which is blocked by #6939. This PR is just a preparation for the next task after hybridization.

So I am fine addressing your review comments in this PR itself!
Thanks!

@seanlip
Copy link
Member

seanlip commented Jun 17, 2019

Thanks @YashJipkate! Full LGTM from me. But please file an issue for #6919 (comment), assign it to yourself, and plan to take care of it as part of your project.

@seanlip
Copy link
Member

seanlip commented Jun 17, 2019

Also since this change is mechanical I am happy to merge it once the Travis checks pass.

@YashJipkate
Copy link
Contributor Author

@seanlip we already have an issue regarding separation of constants. See #6731. This PR fixes a part of that issue. So may be we can just update its description to apply this to the remaining folders?

@seanlip
Copy link
Member

seanlip commented Jun 17, 2019

Sure, that's fine, as long as it's tracked. Are you planning to take that up?

(I don't want that list of folders to stay in the linter script as a long-term thing...)

@YashJipkate
Copy link
Contributor Author

OK @seanlip I will try to do that right away in a follow up PR since that needs to be done sooner or later!

@seanlip
Copy link
Member

seanlip commented Jun 17, 2019

Thanks, @YashJipkate! I will merge this one now.

@seanlip seanlip merged commit 4e665fa into oppia:develop Jun 17, 2019
@YashJipkate
Copy link
Contributor Author

YashJipkate commented Jun 17, 2019

Also the tests pass. Could this be merged?

Edit: Thanks for merging!

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

Successfully merging this pull request may close these issues.

6 participants