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

[Trivia] Move Trivia lists back home #2028

Merged
merged 4 commits into from
Aug 26, 2018

Conversation

Tobotimus
Copy link
Member

@Tobotimus Tobotimus commented Aug 18, 2018

This still needs discussion, but this means saying no to namespace packages (yay) and also everything I listed on #1973. Discussion on that issue still needs to occur, but I want to get it rolling and make a decision on this soon.

What I've done is move the trivia lists to the redbot/cogs/trivia/data/lists directory. The reason I chose and extra data sub-directory is for the interest of ease of extensibility, the distribution will now include all files in an existing data sub-directory of a package.

This also fixes our issue (which has only just been recently discovered) that locale files haven't been included with the distribution since beta 9, due to a line added in #1420: include_package_data=True. This reverts that change and also greatly simplifies the data file discovery for the distribution. I'm for more maintainable and straightforward code where possible.

Removes red-trivia as a dependency.

Signed-off-by: Toby Harradine <tobyharradine@gmail.com>
Signed-off-by: Toby Harradine <tobyharradine@gmail.com>
* The distribution will now include all files under any data/ sub-directory of a package, as well as all *.po files under any locales/ sub-directory (as it should have been before).

* MANIFEST.in has been simplified to comply with these changes and redbot/cogs/audio/application.yml has been moved to the data/ sub-directory to maintain consistency in how we declare package data.

Signed-off-by: Toby Harradine <tobyharradine@gmail.com>
Copy link
Member Author

@Tobotimus Tobotimus left a comment

Choose a reason for hiding this comment

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

Here are just some explanatory comments.

Pipfile.lock Outdated
@@ -53,6 +53,7 @@
"sha256:474d4bc64cee20603e225eb1ece15e248962958b45a3648a9f5cc29e827a610c",
Copy link
Member Author

Choose a reason for hiding this comment

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

Just a comment: The Pipfile.lock was simply updated as Red-Trivia is no longer a dependency. For some reason it has also included some extra markers - these have no effect so please disregard.

@@ -1,5 +1,3 @@
include README.rst
include LICENSE
include dependency_links.txt
include discord/bin/*.dll
include redbot/cogs/audio/application.yml
Copy link
Member Author

@Tobotimus Tobotimus Aug 18, 2018

Choose a reason for hiding this comment

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

The discord/bin/*.dll files don't need to be in our manifest as they're not part of our distribution.

As for the redbot/cogs/audio/application.yml file, I've moved it to redbot/cogs/audio/data/application.yml as we're now including everything in the data/ sub-directory of all packages if it exists (much like we do with 3rd party cogs). This reduces boilerplate and maintains consistency.

@@ -35,11 +33,6 @@ def get_dependency_links():
return file.read().splitlines()


def get_package_list():
core = find_packages(include=["redbot", "redbot.*"])
return core
Copy link
Member Author

Choose a reason for hiding this comment

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

Since this is literally just aliasing a single function call, I removed the function and placed the raw one directly in the setup function for clarity.

Ignore this tomfoolery in the desire for automation. It works, that's
all you gotta know. Don't fuck with this unless you really know what
you're doing, otherwise we lose all translations.
"""
Copy link
Member Author

Choose a reason for hiding this comment

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

So this might be your biggest question, why did I remove this function: it's over-complicated, doesn't encourage extensibility of our data files and objects to maintainability. It is achieved in a much simpler manner with the usage explained below.

@@ -103,9 +67,8 @@ def glob_locale_files(path: Path):
setup(
name="Red-DiscordBot",
version=get_version(),
packages=get_package_list(),
package_data=find_locale_folders(),
include_package_data=True,
Copy link
Member Author

Choose a reason for hiding this comment

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

include_package_data is a very misleading argument which we should never use in the interest of remaining sane. It actually forces setuptools to ignore the package_data argument. Please, for the sake of any future maintainers' sanity, don't bring it back (It's not clearly documented in setuptools' documentation, if you're unconvinced that this is the behaviour, test it on a local machine).

The new package_data argument is used in the way which is recommended in setuptools' documentation, where an empty string as a key applies the rule to all included packages.

from redbot.cogs.trivia import get_core_lists

list_names = get_core_lists()
assert list_names
Copy link
Member Author

Choose a reason for hiding this comment

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

This test came straight from the Red-Trivia repo.

@mikeshardmind
Copy link
Contributor

I think I'd prefer trivia be loaded in as a submodule (still not a namespace package) here for a few practical reasons. The trivia lists don't seem to need to be under the same level of QA scrutiny as the rest of the project. They need to be kept accurate, but there aren't code paths in the questions. Leaving them in their current repo, but pulled in as a submodule allows the more lax review process for those, while gaining the other benefits.

@calebj
Copy link
Member

calebj commented Aug 19, 2018

+1 to what @mikeshardmind said. IMO, trivia lists shouldn't be in the main repo.

@Tobotimus
Copy link
Member Author

@mikeshardmind @calebj If the only incentive to keep them out is to bypass QA, that can easily be done by us devs simply not assigning QA members to trivia lists PRs. Besides, as we know, @MiniJennJenn manages the trivia lists, is the only one who makes PRs to add trivia lists, and those trivia lists come from #12. I don't see how this is worth separating the repos or overengineering the solution to this "problem".

Finally, does this argument stack up against those I made in #1973? If you have disagreements with what I've stated there, you're welcome to point them out.

@Tobotimus
Copy link
Member Author

Tobotimus commented Aug 19, 2018

I should probably think again before responding. For some reason I wasn't even thinking about git submodules, personally I've never used them but I understand now.

This would flatten the versioning system and it would keep them in the Red-DiscordBot distribution, which are both good things and solve two of the problems on #1973. The 3rd problem (neglect and separation) I could resolve by simply linking the ZenHub boards for the two repos (although I'm not convinced why we should separate the repos in the first place, esp. if we're only going to link their issue/PR boards back up again).

I'll look into using submodules. Thanks for your suggestions guys.

@Tobotimus
Copy link
Member Author

After a bit of research and testing, I've decided against the proposition of using submodules. These are my reasons:

  • Cloning submodules includes everything which would be located in that submodule, as shown in the following image:
    image
    This means we'd have to be more specific in our globs for package_data in setup.py - part of this PR was to make that more general to simplify the process of adding data files in the future.
  • (the main reason) When the submodule is added and pushed to this main repo, it points to a specific commit on the submodule's repo, so if there any updates to the trivia lists we'd like to include in the next release, we'd have to open a new PR over here to update them. This is annoying and is a similar problem to the one we have now of maintaining separate release cycles on PyPI, and having to update the version pin on this repo every time Red-Trivia makes a new release.

So for those reasons I'm sticking to this approach here.

@mikeshardmind
Copy link
Contributor

While that's correct, we don't actually need anything but the yml files to exist in that repo if we go that route. I'm still going to advocate the submodule route due to this, but I'm not strictly opposed to simply moving it all back here.

@Tobotimus
Copy link
Member Author

We'd need the tests and Travis config in there at the least since we're not removing the CI on the lists. Besides, that wasn't my main gripe, it was more having to update the head of the submodule every time the trivia lists change.

@mikeshardmind
Copy link
Contributor

Right... Just move them back then.

@Tobotimus Tobotimus added Type: Fix and removed Status: Needs Discussion Needs more discussion. labels Aug 21, 2018
@Tobotimus Tobotimus added this to the Beta 20 milestone Aug 23, 2018
@Tobotimus Tobotimus added QA: Bypassed QA is unnecessary. and removed QA: Unassigned labels Aug 24, 2018
@Tobotimus
Copy link
Member Author

Despite the mixed feelings about this I'm putting it into beta 20 as a possibly temporary fix for the namespace package issues. It's also a permanent fix for all of our missing translations, and that certainly needs to be fixed for beta 20. Personally I think the trivia files are going to stay where they are regardless.

@Tobotimus Tobotimus merged commit e6495bc into Cog-Creators:V3/develop Aug 26, 2018
@Tobotimus Tobotimus deleted the V3/vendor_trivia branch August 26, 2018 13:39
@Jackenmen Jackenmen added the Type: Bug Unexpected behavior, result, or exception. In case of PRs, it is a fix for the foregoing. label Jul 15, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
QA: Bypassed QA is unnecessary. Type: Bug Unexpected behavior, result, or exception. In case of PRs, it is a fix for the foregoing.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants