Package Details: mypy-git 1.9.0.r40.ga00fcba-1

Git Clone URL: https://aur.archlinux.org/mypy-git.git (read-only, click to copy)
Package Base: mypy-git
Description: Optional static typing for Python 2 and 3 (PEP484)
Upstream URL: https://github.com/JukkaL/mypy
Keywords: development
Licenses: MIT
Conflicts: mypy
Provides: mypy
Submitter: eigengrau
Maintainer: xiota
Last Packager: xiota
Votes: 12
Popularity: 0.000000
First Submitted: 2015-10-02 07:27 (UTC)
Last Updated: 2024-03-13 20:20 (UTC)

Required by (63)

Sources (1)

Latest Comments

1 2 3 Next › Last »

gesh commented on 2024-03-13 12:53 (UTC)

Fair enough

xiota commented on 2024-03-13 11:59 (UTC)

re 1.10.0 being an invalid base number ... trying out mypy 1.10 ...

What you wrote demonstrates the problems with using "(n+1)+dev" and other non-monotonic versioning schemes. There is no such release version, yet. Dropping or overlooking the +dev suffix is too easy, making discussions about versions confusing.

gesh commented on 2024-03-13 11:07 (UTC)

Ah, correct -- I had attempted to manually run the commands, which obviously caused some trouble. Sorry for the noise.

Fair enough in re the discussion being academic -- though if you want, I think you could try requesting it be orphaneed.

In re 1.10.0 being an invalid base number -- not sure that's up to us to decide. If upstream wants to number its versions 1.9, 1.10+dev, 1.10, then we should use that (barring this breaking vercmp or the pkgver format). Though I am unsure how to ensure that in this case -- appending a string to a version generally can't make a smaller version. Perhaps by making sure the version string is always of form BASE_VER-dev.rN.gSHA?

Regardless, that's up to you -- my only interest in the package was for trying out mypy 1.10 to make sure an error I was seeing was due to the code and not due to upstream using 1.9 while repos have 1.8.

xiota commented on 2024-03-12 23:02 (UTC) (edited on 2024-03-12 23:13 (UTC) by xiota)

fatal: ambiguous argument '..v1.9.0': unknown revision or path not in the working tree.

None of the commands in the pkgver() function I suggested produce that argument. Looks like you are running different commands or have left over junk in your src folder. Build in clean chroot or delete old src and pkg directories.

Here is an excerpt of output from makepkg -Cf (no error):

==> Starting pkgver()...
==> Updated version: mypy-git 1.9.0.r39.gea49e1f-1
==> Removing existing $pkgdir/ directory...
==> Entering fakeroot environment...

Notes:

  • I did have a different bad argument, but it didn't affect the output. Have edited to fix.
  • The first block in the last comment (starting git checkout...) won't work because it produces output besides the version string.
  • The second code block, running mypy.version produces wrong version string 1.10.0.r38.gea49e1f. There is no released/tagged version 1.10.0.
  • None of this matters much because maintainer is MIA.

gesh commented on 2024-03-12 17:43 (UTC) (edited on 2024-03-12 17:47 (UTC) by gesh)

That doesn't work -- the release tags are off the mainline branch, so am getting

fatal: ambiguous argument '..v1.9.0': unknown revision or path not in the working tree.

If you really insist, you could do:

git checkout $(git log -n 1 --pretty=format:%H -- mypy/version.py)^
git tag -f makepkg-"$(python -c 'import mypy.version as mp; print(mp.__version__)' | sed 's/+dev.*//')"
git switch master
git describe --tags --long --match='makepkg*' | sed 's/^makepkg-//' | sed 's/^v//;s/\([^-]*-g\)/r\1/;s/-/./g'

Or you could fixup the rendering of the version as given by version.py:

_version="$(python -c 'import mypy.version as mp; print(mp.__version__)' | sed 's/+dev.*//')"
_commits="$(git rev-list --count $(git log -n 1 --pretty=format:%H -- mypy/version.py)...HEAD)"
_head="$(git rev-parse --short=7 HEAD)"
printf '%s.r%s.g%s' "$_version" "$_commits" "$_head"

xiota commented on 2024-03-12 16:56 (UTC) (edited on 2024-03-12 23:05 (UTC) by xiota)

Using mypy.version produces version strings with the wrong format: 1.10.0+dev.ea49e1fa488810997d192a36d85357dadb4a7f14

I would suggest the following, which produces 1.9.0.r39.gea49e1f:

pkgver() {
    cd "${_gitname}"
    local _version=$(git tag | sed -E 's/^[^0-9]+//' | sort -rV | head -1)
    [ git rev-list v${_version} > /dev/null 2>&1 ] && local _version_prefix=v
    local _revision=$(git rev-list --count --cherry-pick "${_version_prefix:-}${_version}"...HEAD)
    local _hash=$(git rev-parse --short=7 HEAD)
    printf '%s.r%s.g%s' "${_version:?}" "${_revision:?}" "${_hash:?}"
}

This package also needs to be updated to PEP 517 install method.

gesh commented on 2024-03-12 16:27 (UTC)

In case anyone needs it, this version() works:

pkgver() {
    cd "${_gitname}"
    python -c 'import mypy.version as mp; print(mp.__version__)'
}

eigengrau commented on 2019-04-27 14:12 (UTC)

@alex.shpilkin Thank you for the pointer. As for the version tag: it’s not picked up because newer release tags were only assigned to release commits not merged into the master branch. It also seems that it’s still a bit awkward running both mypy and mypy-extensions from their respective master branches, since mypy pins its mypy-extensions requirement to a distribution version not supplied by mypy-extensions when built from git (one would need to patch mypy’s setup.py).

Since mypy is part of the community repo now I’m orphaning the package. In case anyone needs the dev build feel free to take over.

alex.shpilkin commented on 2019-04-27 10:53 (UTC)

This does not build in a clean chroot (e.g. using aurutils), complaining about missing 'setuptools' (missing python-setuptools dependency?). The version is also not picked up correctly from the source code for some reason: my mypy-git build from post-0.700 sources still claims to be 0.520.r1256.