Hi,

I am having trouble running 2.3.0:

$ roundup-server --help
...
File "/path/to/virtualenvs/roundup/lib/python3.11/site-packages/roundup/mailer.py", line 24, in <module>
    from roundup import __version__
ImportError: cannot import name '__version__' from 'roundup' (/path/to/virtualenvs/roundup/lib/python3.11/site-packages/roundup/__init__.py)


Adding this to the mentioned __init__.py file fixes the problem:

__version__ = '2.3.0'


It seems that nobody is actually using this software - otherwise, I can't imagine how this problem could have slipped through the release process.

Hi Toni:

That is very strange. I just ran the following:

   % python3 -m venv .
   % bin/activate
   (v)% pip3 install -U pip  # get version 24.0
   (v)% pip3 install roundup
    Collecting roundup
      Downloading roundup-2.3.0.tar.gz (3.9 MB)
       ---------------------------------- 3.9/3.9 MB 3.4 MB/s eta 0:00:00
      Installing build dependencies ... done
      Getting requirements to build wheel ... done
      Installing backend dependencies ... done
      Preparing metadata (pyproject.toml) ... done
      Building wheels for collected packages: roundup
      Building wheel for roundup (pyproject.toml) ... done
      Created wheel for roundup: filename=roundup-2.3.0-py3-none-any.whl [...]
      Successfully built roundup
      Installing collected packages: roundup
      Successfully installed roundup-2.3.0
    (v)% bin/roundup-server --help

    Usage: roundup-server [options] [name=tracker home]*

    Options:
     -v            print the Roundup version number and exit
     -h            print this text and exit
     -S            create or update configuration file and exit
     -C <fname>    use configuration file <fname>
    [...]


It works as expected. If I run (still in the venv):

  (v)% python3
  Python 3.8.10 (default, Nov 22 2023, 10:22:35)
  [GCC 9.4.0] on linux
  Type "help", "copyright", "credits" or "license" for more information.
  >>> from roundup import __version__
  >>> __version__
  '2.3.0'
  >>> import sys
  >>> sys.modules['roundup']
  <module 'roundup' from '/[...]/develop/roundup/v/lib/python3.8/site-
packages/roundup/__init__.py'>

again works as expected and verifies that I am getting the roundup from the venv
and not from somewhere else on my system.

The __version__ variable in roundup/__init__.py is used by setup.py
to produce the version string in the published source tarball. So it's extremely
unlikely that __version__ was missing from the end of roundup/__init__py since it
would cause the build to fail.

How did you install Roundup 2.3.0? What OS are you running? What version of pip?

While the number of people using Roundup is not as large as I would like, saying
nobody uses it is incorrect.

It looks like I had a broken file in my pip cache. After cleaning the cache, uninstalling and re-installing the package, it worked.

> It looks like I had a broken file in my pip cache

Wow that's annoying. I'm glad it's fixed.

Hi John,

On Mon, Apr 22, 2024 at 04:08:45PM +0000, John Rouillard wrote:
> John Rouillard added the comment:
> > It looks like I had a broken file in my pip cache
> Wow that's annoying. I'm glad it's fixed.

the file was not technically broken, but the code in the file was
broken. I had just installed it today, although the file in the cache
was there for a bit longer already - I had played with roundup before.

The __init__.py in my broken archive was empty, while the __init__.py in
the current archive is several hundred bytes long and has all the
information. So I presume that someone uploaded a new archive with the
same version number.

On a side note, where can I get 2.4.0?

Thank you,
Toni

Hi Toni:

In message <ZiaTKl8lCD0lAl48@laptop-t.office.oeko.net>,
Toni Mueller writes:
>On Mon, Apr 22, 2024 at 04:08:45PM +0000, John Rouillard wrote:
>> John Rouillard added the comment:
>> > It looks like I had a broken file in my pip cache
>> Wow that's annoying. I'm glad it's fixed.
>
>the file was not technically broken, but the code in the file was
>broken. I had just installed it today, although the file in the cache
>was there for a bit longer already - I had played with roundup before.
>
>The __init__.py in my broken archive was empty, while the __init__.py in
>the current archive is several hundred bytes long and has all the
>information. So I presume that someone uploaded a new archive with the
>same version number.

AFAIK you can't overwrite releases on PyPi. You need to generate a new
release with a new version number. (E.G. there are two roundup 2.3.0
beta releases on test.pypi.because of a packaging screwup.) There has
been some discussion about permitting overwriting of releases though.

It sounds like there was a glitch during the download. However since
the tarball is compressed, I would expect the file would be unusable
past the point of corruption so....

The tarball that is built is unpacked and tested. Then that exact same
tarball is uploaded using twine. I don't downloaded the file again
from pypi and compare the gpg signature though. I assume the upload
was successful (and so far it has been).

>On a side note, where can I get 2.4.0?

2.4.0 beta should be released late May with a 2.4.0 to be released in
July.

If you want to work with the current development head release that
will be 2.4.0 (note it doesn't have the web-component class helper
yet, their last day with me is 15 May), you can clone from the
mercurial repo using the directions at:
https://roundup-tracker.org/code.html.

You can also clone from the git repo
https://github.com/roundup-tracker/roundup we use for CI.