Hello Andreas,
Referring to this email as a recap.
Running the latest clone, I get on all binaries an identical error:
$ run_lefse
File "/usr/bin/run_lefse", line 25
parser.add_argument('-r',dest="rank_tec", metavar='str',
choices=['lda','svm'], type=str, default='lda',
^
TabError: inconsistent use of tabs and spaces in indentation
Looking at how the tab entries / spaces are, it seems to be completely
mixed in almost all the python files. It looks like I would have to run
autopep8 to correct this behaviour, but that would result in the bigger
patch size replacing all the *.py but this is unavoidable.
So it is suggested to preserve this from getting changed (from lefse
import *).
Running "python3 run_lefse.py" within the working directory, I get the
help output for run_lefse, so this is working. Installing lefse deb on
my system and running run_lefse in terminal:
$ run_lefse
Traceback (most recent call last):
File "/usr/bin/run_lefse", line 7, in <module>
from lefse import *
ModuleNotFoundError: No module named 'lefse'
Is this normal expected behaviour before I push? Why would run_lefse.py
and run_lefse differ when executed differently, assuming they are identical.
Kind regards,
Shayan Doust
On 09/09/2019 20:35, Shayan Doust wrote:
> Hello Andreas,
>
>> I was running routine-update and have build the package. When calling
>> a random binary I experienced:
>>
>>
>> $ plot_features
>> Traceback (most recent call last):
>> File "/usr/bin/plot_features", line 6, in <module>
>> from .lefse import *
>> ModuleNotFoundError: No module named '__main__.lefse'; '__main__' is
> not a package
>
> I experienced the same thing, but I assumed my direct execution was
> wrong and maybe lefse was meant to be used / integrated within something
> in the python ecosystem. If I recall correctly, I got an error (I think
> it was different to this) when executing lefse pre the python3 conversion.
>
>> As far as I can see this is actually a Python3 conversion issue
>> I really wonder whether this chunk of the patch should be rather
>> droped and
>>
>> from lefse import *
>>
>> should remain.
>
> I assume so. I don't think this was result in a complete breakage. I'm
> fairly misinformed with python but I am not too sure of the idea behind
> "from lefse import *" getting converted to "from .lefse import *". I
> will take another look at this. Annoyingly, this test script is broken
> even before the python3 conversion.
>
>> Asking on Debian Mentors list is an option to clarify the test suite
>> issue. We could even upload the package to new queue. It will last
>> some time anyway to pass the queue. The package is also not totally
>> broken (binaries are starting, some tests are passing). Its hard to
>> tell whether those failures are practically important or not. We could
>> hope for user bug reports.
>
> From my experience with debian mentors mailing list, people are
> understandably busy and I haven't received any replies with previous
> emails. I agree, the package is not totally broken because the direct
> source clone acts up the same way as this package, so
> functionality-wise, I assume there is very little to no deviation. Maybe
> as you suggest, it is best to upload and wait for user bug reports -
> that will be an experience too and should rule out any packaging faults.
> FAST has a low traffic anyways.
>
>>> On the side, I have decided to work on another package. It seems like
>>> even this is getting to be a slight pain (depends on gatb-core and
>>> modifying cmake to use debian packaged gatb-core seems to bring a whole
>>> lot of issues during linkage). I am currently waiting until upstream
>>> replies or someone via the mentors mailing list to give a suggestion.
>>
>> I've seen and appreciated your commits. :-)
>
> Thanks :). These packages have been quite an experience and something
> I'd continue doing for debian med. Simka should be an easy program to
> package once I figure out why the object linkage fails.
>
>
> Kinds regards,
> Shayan Doust
>
> On 09/09/2019 20:19, Andreas Tille wrote:
>> Hi Shayan,
>>
>> On Mon, Sep 09, 2019 at 07:19:05PM +0100, Shayan Doust wrote:
>>>
>>> Just an update. Apologies for the somewhat degraded and slower performance.
>>
>> Really no need to apologize - I simply had a real life weekend as well.
>> ;-)
>>
>>> Please check the patch as mentioned for just an instance to make sure I
>>> am on a satisfactory path before I push for a changelog. As stated, one
>>> file needed to have a consistent tab / space correction due to failing
>>> apt install which resulted in a slightly bigger patch than preferred.
>>> I'd hate to finalise on something that isn't good :).
>>
>> I was running routine-update and have build the package. When calling
>> a random binary I experienced:
>>
>>
>> $ plot_features
>> Traceback (most recent call last):
>> File "/usr/bin/plot_features", line 6, in <module>
>> from .lefse import *
>> ModuleNotFoundError: No module named '__main__.lefse'; '__main__' is not a package
>>
>>
>> As far as I can see this is actually a Python3 conversion issue
>> I really wonder whether this chunk of the patch should be rather
>> droped and
>>
>> from lefse import *
>>
>> should remain.
>>
>>> On top of this, regarding FAST, upstream has been really silent (not
>>> usually like this). I could give them a week or so, but what is the
>>> worst case with regards to this package? It seems like the test suite is
>>> troublesome (more than probably a machine trouble / misconfiguration or
>>> FAST nitpicking a specific opencl platform) and if there is no response
>>> from upstream, I won't be able look into the test suite. Does that mean
>>> theoretically abandoning this package for some amount of time either
>>> until the test suite can be checked by another peer with the correct
>>> hardware & opencl knowledge?
>>
>> Asking on Debian Mentors list is an option to clarify the test suite
>> issue. We could even upload the package to new queue. It will last
>> some time anyway to pass the queue. The package is also not totally
>> broken (binaries are starting, some tests are passing). Its hard to
>> tell whether those failures are practically important or not. We could
>> hope for user bug reports.
>>
>>> On the side, I have decided to work on another package. It seems like
>>> even this is getting to be a slight pain (depends on gatb-core and
>>> modifying cmake to use debian packaged gatb-core seems to bring a whole
>>> lot of issues during linkage). I am currently waiting until upstream
>>> replies or someone via the mentors mailing list to give a suggestion.
>>
>> I've seen and appreciated your commits. :-)
>>
>>> Thanks for the support once again & kind regards,
>>
>> Thanks a lot for your work
>>
>> Andreas.
>>
>
Attachment:
signature.asc
Description: OpenPGP digital signature