I've done a quick and dirty test - automatized splitting all commands and
measuring import time differences for koji_cli/commands.py (split + python
-X importtime). Average for 100 runs is 195ms for split variant and 194ms
for non-split. So, at least under py3.7 it is not an issue.
st 26. 2. 2020 v 21:18 odesílatel Michael McLean <mikem(a)redhat.com> napsal:
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...
>
_______________________________________________
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