[yt-dev] Repo cleanup

Brian O'Shea bwoshea at gmail.com
Mon Aug 10 05:55:07 PDT 2015


On Mon, Aug 10, 2015 at 8:47 AM, Nathan Goldbaum <nathan12343 at gmail.com>
wrote:

>
>
> On Monday, August 10, 2015, Brian O'Shea <bwoshea at gmail.com> wrote:
>
>> I'm strongly -1 on removing analysis modules unless there's an
>> exceptionally good reason - not just a vague sense that the code needs to
>> be cleaned out.  For example, my research group uses lots of star
>> particle-related analysis - in particular, generation of galaxy spectra
>> from star particles - and getting rid of it would be bad.  I suggest
>> leaving the 2-point function stuff in the code, but task somebody to update
>> it to yt-3's standards, even it's a low priority.  Just because the core yt
>> devs don't use it doesn't mean it isn't used or useful!
>>
>
> Functionally, what would the difference be? Are you saying that removing
> nonfunctional code would make it less likely for someone to update it?
>
> Removing the code does not preclude someone from updating it, or even make
> it harder really. We're using version control after all, one could always
> just back out my commits that remove it.
>
> I'd argue that the desire to keep the code in the hope that someone will
> update it needs to be balanced against the real danger of someone trying to
> use it, finding its hopefully broken, and then giving up on yt entirelyz
>

Fair enough; in that case, I think it's reasonable to pull the 2-point
stuff.  But we do use the star particle analysis code, and it is working,
so I think we should keep that in.

--Brian


>
>
>>
>>
>> Regarding the boolean objects, we also got a lot of use out of them in
>> yt-2 and I was sad to see that get broken in yt-3.  Andrew, if you decide
>> to work on that I'd be happy to collaborate and be a test subject!
>>
>> --Brian
>>
>>
>>
>>
>>
>
>
>>
>> On Sun, Aug 9, 2015 at 7:35 PM, Nathan Goldbaum <nathan12343 at gmail.com>
>> wrote:
>>
>>> Hi all,
>>>
>>> I'd like to spend some time in the next week or two doing some cleanup
>>> and tidying up on the yt repo.  This comes in two flavors: removing dead
>>> code and adding basic linting tests.
>>>
>>> Dead Code
>>> ---------------
>>>
>>> There are still a number of big chunks of legacy code in the codebase
>>> that aren't called by anything, including:
>>>
>>> * boolean data objects
>>> * reason / reason plot widgets (yt.gui)
>>> * two scripts in the top-level "scripts" directory (pyro_queue.py and
>>> yt_lodgeit.py)
>>> * the top-level "tests" directory
>>> * possibly some of the analysis modules? (star_analysis and
>>> two_point_functions)
>>>
>>> I'm curious what others think about removing some or all of this code.
>>> I'd particularly like to hear if I'm wrong about the code in the list above
>>> or if I've missed any chunks of unused code.
>>>
>>> I do understand the desire to keep the code in the repository in the
>>> hopes that one day someone might make it functional, but I think this
>>> consideration is balanced by how confusing it can be to come across dead
>>> code and then get frustrated after finding weird incompatibilities.
>>>
>>> Basic Linting Tests
>>> -------------------------
>>>
>>> I'd like to catch as many errors as possible by doing basic static
>>> analysis of the yt codebase using pyflakes and flake8.  We already have
>>> coverage with both tools run as part of the test suite, but introducing
>>> errors detected by these tools does not fail the build. I'd like to add a
>>> few of the errors caught by these tools to the test suite itself, making
>>> the tools optional dependencies for the tests. Hopefully these new tests
>>> will be useful and not obnoxious: I'm not talking about enforcing pep8 as
>>> part of the test suite.
>>>
>>> To do this, I think the biggest change necessary is to get rid of all
>>> instances of "import *" throughout the codebase. This will allow us to test
>>> for unused imports (probably shouldn't fail the build) or missing imports
>>> (definitely should fail the build).
>>>
>>> Again, I'd appreciate any comments or objections to this general
>>> approach.
>>>
>>> Thanks for your attention! Sorry for the long e-mail...
>>>
>>> -Nathan
>>>
>>>
>>>
>>> _______________________________________________
>>> yt-dev mailing list
>>> yt-dev at lists.spacepope.org
>>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>>>
>>>
>>
> _______________________________________________
> yt-dev mailing list
> yt-dev at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/attachments/20150810/e8430045/attachment.htm>


More information about the yt-dev mailing list