You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There is a "Commands" table on the Paver DEPR ticket. This covers all of the rows that say "Need to implement".
When choosing replacements: the best-case replacement is when we can simply run the underlying command. For example, I believe that pycodestyle will work out-of-the-box as a replacement for paver run_pep8. This is a very good developer experience, and it means that we don't need to maintain any custom tooling logic in edx-platform. It is possible that this will work for other commands, too, although some tooling configuration may need to be added in order for them to work.
The next-best-case is to have a simple Makefile target. For example, we might need to have make pii_check. If possible, try to avoid writing separate new scripts in edx-platform, as this increases complexity for end-users and adds new burden for edx-platform maintainers.
For each Paver command you replace:
Update the GitHub action that uses it
Remove the old Paver command. Paver is already deprecated, so there is no need to leave the old commands around for backwards-compatibility.
I tried the pycodestyle . command and its working fine, there is a scenario that i face where when i run this command on the terminal it was showing errors in few files but on CI it was not showing any error, after searching and reading i found there is version difference and the version of pycodestyle on my local machine was new which has some rules changes due to which it was complaining for in few file. Overall this pycodestyle . command is working fine.
paver run_stylelint
I tried stylelint command to replace the paver, it runs but gives me 10943 errors in all .scss files which are very hard to fix. If i use this command in CI the check will always fail. As per previous implementation there is a threshold count for violations and if that threshold crosses then they fail the check otherwise the errors are just stored in an external file. My thoughts are to go with the previous implementation logic and use a violation threshold.
paver run_eslint
The same is the case with this command when i use the direct eslint command It gives a lot of errors in .js files which is hard to fix and to pass the CI check.
It's possible that the use of eslint and stylelint direct commands could cause an increase in errors if the rules have become stricter or if new rules have been added.
stylelint and eslint -- good to know, thanks for checking that. I agree with your assessment that the existing violations would be hard to fix, so we will instead need a script to handle the threshhold. I imagine you can use a modified version of paver run_eslint and paver run_stylelint. Could you turn them into scripts under the scripts/ directory, and ensure that they don't use paver or any part of pavelib?
Context
Paver is deprecated:
We would like to fully remove it soon:
There are a small handful of Paver commands remaining in edx-platform. We need to replace these commands in order to fully remove Paver.
Tasks
Tasks
General Guidance
There is a "Commands" table on the Paver DEPR ticket. This covers all of the rows that say "Need to implement".
When choosing replacements: the best-case replacement is when we can simply run the underlying command. For example, I believe that
pycodestyle
will work out-of-the-box as a replacement forpaver run_pep8
. This is a very good developer experience, and it means that we don't need to maintain any custom tooling logic in edx-platform. It is possible that this will work for other commands, too, although some tooling configuration may need to be added in order for them to work.The next-best-case is to have a simple Makefile target. For example, we might need to have
make pii_check
. If possible, try to avoid writing separate new scripts in edx-platform, as this increases complexity for end-users and adds new burden for edx-platform maintainers.For each Paver command you replace:
Timeline
We would like to complete this before the Sumac cut in October so that Paver can be completely removed in the Sumac release.
The text was updated successfully, but these errors were encountered: