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...