ASPP / pelita_template

Default template to get started with the Pelita game.
3 stars 25 forks source link

Do we still need the `groupN` files? #77

Closed Debilski closed 2 months ago

Debilski commented 2 months ago

I somehow forgot whether we still need this file to be different for each group.

In the interest of setting up CI easily (this also holds for the tutors’ bots!) a default convention of bot.py or bots.py or teams.py or __init__.py would certainly be helpful. (This could also be a simple symlink to the real start file or incorporate the compatibility code for older versions of Pelita.)

We don’t need to solve this now but setting up continuous integration for 30 bots from previous years is getting messy when you need to enter each directory and figure out which of these python files is the actual thing that contains the move function.

Alternatively, we could make these bots installable, I guess. Add a pyproject.toml and it might just be enough.

otizonaizit commented 2 months ago

It made sense historically, but I agree that we don't need a different file name anymore. I think we should call it bot.py. We could argue forever about naming it with a plural or naming it team.py or teams.py, but I think the easiest is bot.py.

I don't think making the bots installable is a good idea: we would then need to make sure that they don't have name clashes, that the name in the pyproject.toml matches the TEAM_NAME in some way, etc...

If we agree on bot.py we need to decide very soon and update the docs and the repos...

On Fri 28 Jun, 05:30 +0000, Rike-Benjamin Schuppner @.***> wrote:

I somehow forgot whether we still need this file to be different for each group.

In the interest of setting up CI easily (this also holds for the tutors’ bots!) a default convention of bot.py or bots.py or teams.py or __init__.py would certainly be helpful. (This could also be a simple symlink to the real start file or incorporate the compatibility code for older versions of Pelita.)

We don’t need to solve this now but setting up continuous integration for 30 bots from previous years is getting messy when you need to enter each directory and figure out which of these python files is the actual thing that contains the move function.

Alternatively, we could make these bots installable, I guess. Add a pyproject.toml and it might just be enough.

— Reply to this email directly, view it on GitHub¹, or unsubscribe². You are receiving this because you are subscribed to this thread.☘Message ID: @.***>

––––

¹ https://github.com/ASPP/pelita_template/issues/77 ² https://github.com/notifications/unsubscribe-auth/AACUYC7GI5UB74YDABFBHYDZJVJNBAVCNFSM6AAAAABKBZ25TCVHI2DSMVQWIX3LMV43ASLTON2WKOZSGM4DAMZSG43TMMQ

Debilski commented 2 months ago

I don't think making the bots installable is a good idea: we would then need to make sure that they don't have name clashes, that the name in the pyproject.toml matches the TEAM_NAME in some way, etc...

This could be averted by using namespace modules:

pelita pelita_player.aspp2024.group0.bot pelita_player.aspp2024.group1.bot

But ok maybe that is a little overkill.

Debilski commented 2 months ago

bot.py is fine with me. (For customisation we can still set the TEAM_NAME to groupN when creating the group repos.)

Still, historically, I must have forgotten why we went with groupN.py for such a long time. The naming problem (https://github.com/ASPP/pelita/issues/272) should have been solved in https://github.com/ASPP/pelita/pull/304/commits/c74e3f3ba7f09c368e45e7ac03fbb38edab3adc8 already . So why did we insist on the groupN.py files in Pelita 2.0? For pedagogic reasons? Before 2.0 we had only a groupN folder with factory methods inside (How strange to think of this now and read the GitHub issues.) so we must have made a deliberate decision there.

otizonaizit commented 2 months ago

Let's go for bot.py and TEAM_NAME="groupN" in Heraklion. I'll create the group repos accordingly and update the wiki documentation. Let's leave the understanding of our decisions from 10 years ago to the FOSS historians of the future ;-)