Package Details: mypy-git 1.10.0.r11.gba6febc-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-04-28 04:30 (UTC)

Required by (64)

Sources (1)

Latest Comments

1 2 3 Next › Last »

xiota commented on 2024-08-14 23:20 (UTC) (edited on 2024-08-14 23:23 (UTC) by xiota)

@emilylime I avoid adding workarounds for non-standard use-cases because it clutters the PKGBUILD and often breaks other use cases. I expect your config has problems with most python-* packages. If possible, configure your AUR helper, or write an auxiliary script, to process python packages differently. Try passing -Cc to makepkg.

emilylime commented on 2024-08-14 22:56 (UTC)

The package doesn't build (twice) with --noextract :( I have my AUR helper configured to not overwrite existing source files to reuse build artefacts in devel packages, but the way the package function is written it breaks with multiple *.whl files present, which happens immediately when trying to makepkg --noextract (if you've previously built an older version of the package). I would be very thankful if you could look into fixing this ^^

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.

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"

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__)'
}

1 2 3 Next › Last »