[yt-dev] Repo cleanup

[Nathan Goldbaum]

On Monday, August 10, 2015, Brian O'Shea <bwoshea at gmail.com> wrote:

>
>
> On Mon, Aug 10, 2015 at 8:47 AM, Nathan Goldbaum <nathan12343 at gmail.com
> <javascript:_e(%7B%7D,'cvml','nathan12343 at gmail.com');>> wrote:
>
>>
>>
>> On Monday, August 10, 2015, Brian O'Shea <bwoshea at gmail.com
>> <javascript:_e(%7B%7D,'cvml','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.
>

Thank you, that exactly why I ran this idea by the list. From my cursory
inspection last night it wasn't clear to me last night that it had been
updated. I've just now double-checked and see that I was incorrect.  I will
keep that in mind and also carefully double-check anything else that might
get removed to verify that it has in fact not been updated.


>
> --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
>> <javascript:_e(%7B%7D,'cvml','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/1683bda0/attachment.htm>