Python 3 release - will be 0.7.0 #594
Comments
|
I am also using a source build of catkin_tools with python3 without any problems and would appreciate a new release. |
|
A new release would be appreciated on Debian Buster and Ubuntu Focal. It looks like it depends on |
|
👍 |
|
Cutting a new release would be greatly appreciated. Running |
|
PyPI release is also broken for Python 3.8, because trollius defines Traceback (most recent call last):
File "/home/nim/.local/bin/catkin", line 5, in <module>
from catkin_tools.commands.catkin import main
File "/home/nim/.local/lib/python3.8/site-packages/catkin_tools/commands/catkin.py", line 28, in <module>
from catkin_tools.common import is_tty
File "/home/nim/.local/lib/python3.8/site-packages/catkin_tools/common.py", line 23, in <module>
import trollius as asyncio
File "/home/nim/.local/lib/python3.8/site-packages/trollius/__init__.py", line 21, in <module>
from .base_events import *
File "/home/nim/.local/lib/python3.8/site-packages/trollius/base_events.py", line 42, in <module>
from . import tasks
File "/home/nim/.local/lib/python3.8/site-packages/trollius/tasks.py", line 565
def async(coro_or_future, loop=None):
^
SyntaxError: invalid syntaxThe workaround is: |
|
It would be great to get the new release on all the LTS version of ROS ;) |
|
This is blocking MoveIt releasing into Noetic :-/ |
|
While a new release would be nice, you should be able to install |
Out of curiosity: what feature of |
|
Thanks @gavanderhoorn, that did the trick (for now). @dirk-thomas We've used I don't know enough about Are you suggesting we should, for ROS 1 Noetic, switch fully to colcon? Can you look at our source install instructions and provide example replacement commands please? We should also probably move this to a standalone moveit issue, if this is what you are proposing, rather than spam this issue. |
|
I was just asking because Just from a brief look at the instructions I didn't see any special features being used which aren't available in any of the other tools (building, ignoring specific packages, passing CMake build type. I only noticed that MoveIt use |
it may not be actively maintained, but Colcon is also not recommended for ROS 1 use. At least it wasn't last time I checked. At the very least it doesn't support a This leaves us with plain |
|
My two cents: a LOT of people use catkin_tools. One thing is: "we don't want to support any further catkin_tools to focus on something else (Colcon?)", but 0.45 was release 13 months ago and few commits have been done in the midtime. Can we just have a release to make those changes available to everybody? |
That is certainly the case. It doesn't change the fact though that nobody seems to be willing to actively maintain it. Afaik @mikepurvis is currently the only person putting any effort in it.
Maybe @mikepurvis can clarify what the pending items are which need to happen before the next release. Then anyone interested in a sooner release can consider to help on those. |
|
@dirk-thomas at a high level: we've switched to Our MoveIt 1 |
|
I'm going to try to make a release today or failing that this week at @davetcoleman's request, but I simply don't have the bandwidth to keep this going. So we need someone new to step up if you all are going to continue to use it. |
|
Thanks @wjwwood !! |
And by this I mean we need people to help @mikepurvis and others, who are still active. I was thinking more the future. @mikepurvis should I release as-is? I'm going to check into the reported issue with Python 3.8 first, but is there anything else that should block a release? |
|
I misunderstood the report about 3.8, I see now that it was already fixed on master. Ok, I'll assume master is good to go (I tried it out on 3.8) and release it. |
|
catkin_tools 0.5.0 is released, but there's still an issue with the deb version. I'm looking into that now... Also, I see a new commit on master, so I'll probably do a 0.5.1 release as soon as I figure out why trollius is still a deb depend. |
|
@wjwwood: Is this related to the following error I received: |
I just received the same error when installing to a |
|
I’m aware of the issues and I’m working on a fix. Sorry for the disruption. |
|
|
I've released 0.6.0 which rolls back to the state of 0.4.5 to fix everyone. I'll make a 0.7.0 release when I'm sure it won't break everything again. It may take a few minutes to propagate. |
I am volunteering to help. I can start by doing some PR reviews and we can take it from there? |
|
Hi @varunagrawal, thanks for the offer! |
|
Alright, sounds good. If anything changes, please do let me know. |
catkin_tools is not fully functional in Python 3 (see: catkin/catkin_tools#594), thus we use Python 2.
fresh install ran into the problem myself and found the solution burried here: catkin/catkin_tools#594
which is required additionally to python3-catkin-tools due to a wrongly configured Debian dependency. See catkin/catkin_tools#594.
|
When will this be released on pip and/or apt? |
|
0.7.1 is on conda-forge :) conda-forge/catkin_tools-feedstock#18 |
|
Yes, thanks for the reminder. I just released the new version for pip. I've also been trying to get @wjwwood to update the apt package on packages.ros.org, but I have been repeatedly put off for months, so I assume that that's not going to happen anytime soon. |
|
I was trying to release onto ROS's packages.ros.org repository (as apt) and also on PyPi for pip, but I'm getting an error in the @timonegk did you run into this at all? I'm using this setup: |
|
Jumping to (maybe) help move this along. Would the following docker image help? FROM ubuntu:18.04
RUN apt-get update && apt-get install -y \
build-essential \
wget \
python3-dev \
python3-setuptools \
python3-wheel \
&& rm -rf /var/lib/apt/lists/*
RUN wget https://github.com/catkin/catkin_tools/archive/refs/tags/0.7.1.tar.gz && \
tar xf 0.7.1.tar.gz && \
rm -rf 0.7.1.tar.gz
RUN cd catkin_tools-0.7.1 && \
/usr/bin/python3.6 setup.py sdist bdist_wheelI couldn't reproduce your issue, but you should be able to build the artifact. |
[...]
@wjwwood note the |
|
Actually I don't have a custom python installation. But I do have an updated setuptools and usr local lib is the right place for non-apt dependencies. It might be an issue that it doesn't work with newer versions of setuptools which is something I don't want to ignore. It's recommended to use the latest version when releasing to pypi. Thanks for the suggestions though, I'll look into it more tomorrow. |
|
I did not run into this problem. (And I did already successfully release the package on PyPi.) |
@timonegk you probably already realize this, but next time you release, do at least
In case anyone else ran into this problem... It turned out to be a bug in the version of I was surprised at this issue (and I still think it has to do with something "special" we're doing in our 0.7.1 should now be available via packages.ros.org too. I really am sorry it took so long, but finally I got the Python3 only version sufficiently tested and released for From now on, updating the version should be quick (now that the Python3 only is not new), so just ping me on an issue if you want a new one @timonegk. I actually had quite a few small issues to resolve when releasing the debs for I will also still follow up with someone about maybe just pulling from your PPA, rather than us making and uploading debs. That becomes even easier for me, since all we will do is run a build farm job on demand after you update the PPA to pull in new stuff. But I can do manual releases until then. Despite the testing, if issues come up, please let me know and I'll fix it as quick as I can (now that it's live). |
Actually I misunderstood you, I see you've already fixed that by doing a 0.7.1 release locally. Sorry, my bad :) Still I think, in the future, you may be able to fix that by putting something like |
@wjwwood A |
|
Hmm, the |
|
@wjwwood 'installed' does not matter, point is what is in the source package and where is it versioned. I just had a look at the PPA and the |
|
I uploaded 0.7.0 with the wrong stdeb.cfg, and after the fix I was not able to upload it with the same version, so I had to increase it to 0.7.1. |
|
Sorry, I didn't mean to imply that they way @timonegk did it was wrong, that's certainly not the case. I agree having the tagged version be consistent with what is released is a good thing. And version numbers are essentially free. I was just pointing out that if you need to do so (just information that might be useful) you can adjust the "debian version", It's kind of peculiar (compared to other packaging processes) that we include this packaging information in the source repository. But I agree that keeping the |
|
Having the packaging info in-source I think kind of implies that it should be a |
This was a workaround for catkin/catkin_tools#594. It is no longer necessary since python3-catkin-tools 0.7 added the proper dependency.
This was a workaround for catkin/catkin_tools#594, which is no longer needed because python3-catkin-tools 0.7 added the required dependency.
and others
Would be great to have a released version of catkin_tools which works well for Python 3. Myself and some colleagues have been using this from source in Py3 virtualenvs for a few weeks and not discovered anything horrific; are there any objections before we ask @wjwwood to pull the lever?
The text was updated successfully, but these errors were encountered: