I've assumed we'd eventually split commands.py (and for that matter
kojihub.py). When we reach that point, I don't think git blame output will
be a blocker. It's not so much losing history as putting an event into the
history that most git tools don't understand fully.
I do think this is a much larger discussion than the OP. I don't think we
necessarily have to immediately split commands.py in order to add new
commands in a different file. That said, however we do add new commands is
likely to be the new standard, so we should think about it carefully.
I am concerned about doing it right. If we were to simply split this file
up yet keep the rest of our cli framework the same, I fear we'd slow down
load time for the tool (by having to load a separate module for each
command on each invocation). There are certainly ways around this, but it's
not clear to me what the best path is.
Do folks have examples of other python tools that they feel are good
examples worthy of emulation in this regard?
On Wed, Feb 26, 2020 at 2:17 PM Ken Dreyer <ktdreyer(a)ktdreyer.com> wrote:
You're right that "git blame" is not quite as simple to
use after a
refactor like that. On the other hand, I think that is exactly the kind of
break-with-history trade-off that we should be making in Koji to make it
easier for contributors to enjoy writing Koji code.
- Ken
On Wed, Feb 26, 2020, 6:29 AM Tomas Kopecek <tkopecek(a)redhat.com> wrote:
> And one argument against - effectively losing git history for newly split
> files.
>
> st 26. 2. 2020 v 13:51 odesílatel Tomas Kopecek <tkopecek(a)redhat.com>
> napsal:
>
>>
>>
>> út 25. 2. 2020 v 20:11 odesílatel John Florian <jflorian(a)doubledog.org>
>> napsal:
>>
>>> On 2020-02-25 10:32, Ken Dreyer wrote:
>>> > The cli/koji_cli/commands.py file is massive at this point, and I
>>> > don't want to make that problem worse. I (naively) think it would
make
>>> > more sense to refactor cli/koji_cli/commands.py into a
>>> > cli/koji_cli/commands/ directory and to put each sub-command into its
>>> > own Python file.
>>>
>>
>> I've two points to that:
>> 1) I was more thinking about adding things from koji-tools more as a
>> plugins (most users don't need these), which would mitigate big file
>> problem.
>> 2) one file approach - Yes, I'm more or less +1 here. I've split
>> original `koji` file to those koji_cli/commands + lib in one point, but
>> stopped there because of other priorities. Anyway, the main reason in old
>> times AFAIK was speed of loading many small files by interpreter. I don't
>> think it is the issue anymore and I would like to go one step further -
>> splitting commands.py to commands module.
>>
>> Mike, were there some other (still valid) reasons to not do that? (And
>> we can also do the same with kojid).
>>
>>
>>> Whenever I've wandered in there, I have wished for this. I've taken
>>> the
>>> "commands" package approach in most all my private tools, even for
>>> cases
>>> where there's only two sub-commands, and much prefer it if for no other
>>> reason than clean obvious lines of scope and dependency. I can then
>>> neatly put things that they may all share in commands/__init__.py such
>>> as maybe a dynamic dispatcher to enforce that function names are
>>> derived
>>> from CLI keywords. (I merely use that as an example, I don't recall if
>>> koji has any such incongruities.) But ... I'm very much a person who
>>> prefers many small files to a few giant ones and this is only my $0.02.
>>> _______________________________________________
>>> koji-devel mailing list -- koji-devel(a)lists.fedorahosted.org
>>> To unsubscribe send an email to koji-devel-leave(a)lists.fedorahosted.org
>>> Fedora Code of Conduct:
>>>
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>>> List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
>>> List Archives:
>>>
https://lists.fedorahosted.org/archives/list/koji-devel@lists.fedorahoste...
>>>
>>
>>
>> --
>>
>> Tomas Kopecek <tkopecek(a)redhat.com>
>> Release Engineering Development, RedHat
>>
>
>
> --
>
> Tomas Kopecek <tkopecek(a)redhat.com>
> Release Engineering Development, RedHat
> _______________________________________________
> koji-devel mailing list -- koji-devel(a)lists.fedorahosted.org
> To unsubscribe send an email to koji-devel-leave(a)lists.fedorahosted.org
> Fedora Code of Conduct:
>
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
>
https://lists.fedorahosted.org/archives/list/koji-devel@lists.fedorahoste...
>
_______________________________________________
koji-devel mailing list -- koji-devel(a)lists.fedorahosted.org
To unsubscribe send an email to koji-devel-leave(a)lists.fedorahosted.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/koji-devel@lists.fedorahoste...