There are two version of my little tool:
https://pypi.python.org/pypi/tbzuploader/2017.11.0
https://pypi.python.org/pypi/tbzuploader/2017.12.0 Bug: The pypi page looks ugly.
In the last update a change in README.rst cases a warning:
user#host> rst2html.py README.rst > /tmp/foo.html
README.rst:18: (WARNING/2) Inline emphasis start-string without end-string.
README.rst:18: (WARNING/2) Inline emphasis start-string without end-string.
Now the pypi page looks ugly :-(
I use this recipe to do CI, bumpversion, upload to pypi: https://github.com/guettli/github-travis-bumpversion-pypi
How could I ensure that no broken README.rst gets released any more? With other words I want to avoid that the pypi page looks ugly.
Dear detail lovers: Please don't look into the current particular error in the README.rst. That's is not the question :-)
Update
As of Sep 21, 2018, the Python Packaging Authority recommends an alternative command twine check. To install twine:
pip install twine
twine check dist/*
Note that twine requires readme_renderer. You could still use readme_renderer, and you only need to install twine if you want its other features, which is a good idea anyway if you are releasing to PyPI.
From the official Python packaging docs, Uploading your Project to PyPI:
Tip: The reStructuredText parser used on PyPI is not Sphinx! Furthermore, to ensure safety of all users, certain kinds of URLs and directives are forbidden or stripped out (e.g., the .. raw:: directive). Before trying to upload your distribution, you should check to see if your brief / long descriptions provided in setup.py are valid. You can do this by following the instructions for the pypa/readme_renderer tool.
And from that tool's README.rst:
To check your long description's locally simply install the readme_renderer library using:
$ pip install readme_renderer
$ python setup.py check -r -s
Preamble
I had a readme which would not render on PyPi, other than the first element on the page (an image). I ran the file against multiple validators, and tested it against other renders. It worked perfectly fine everywhere else! So, after a long, nasty fight with it, and numerous version bumps so I could test a PyPi revision, I tried reducing the file to a bare minimum, from which I'd build it back up. It turned out that the first line was always processed, and then nothing else was...
Solution
Discovering this clue regarding the first line, I then had an epiphany... All I had to do was change the line endings in the file! I was editing the file in Windows, with Windows line endings being tacked on implicitly. I changed that to Unix style and (poof!) PyPi fully rendered the doc!
Rant...
I've encountered such things in the past, but I took it for granted that PyPi would handle cross platform issues like this. I mean one of the key features of Python is being cross platform! Am I the first person working in Windows to encounter this?! I don't appreciate the hours of time this wasted.
You could try if rstcheck catches the type of error in your readme. If it does, run it after pytest in your script section. (and add it in your requirements ofc).
Related
Is it possible to programmatically check if a wheel (whl) is compatible with the chosen Python installation before attempting to install?
I'm making an automated packages installer (packages needed for my Python project to work), and I need to only attempt to install compatible pkgs, so if there are errors, I know they are only from the compatible modules and I should see what happened (not errors also from incompatible pkgs, which I wouldn't care). Example: I'd have wheels for Python 3.5 and 3.7, and in a 3.5 installation, 3.7 wheels could not be tried to be installed.
I've tried pkginfo (https://pypi.org/project/pkginfo/), but on wheel.supported_platforms, it returns an empty array and I can't do anything with that (a wheel with "any" or with "win32" on their name in the platform part, returned an empty array, so I can't use that, it seems).
Also tried the output from python -m pip debug --verbose, but the following appears:
WARNING: This command is only meant for debugging. Do not use this with automation for parsing and getting these details, since the output and options of this command may change without no
tice.
This makes the command not possible to use, even though bellow that it prints the "Compatible tags", which more or less I could use to determine if a wheel is supported or not from its name. Example of those "Compatible tags" in a Python array:
['cp39-cp39-win_amd64', 'cp39-abi3-win_amd64', 'cp39-none-win_amd64', 'cp38-abi3-win_amd64', 'cp37-abi3-win_amd64', 'cp36-abi3-win_amd64', 'cp35-abi3-win_amd64', 'cp34-abi3-win_amd64', 'cp
33-abi3-win_amd64', 'cp32-abi3-win_amd64', 'py39-none-win_amd64', 'py3-none-win_amd64', 'py38-none-win_amd64', 'py37-none-win_amd64', 'py36-none-win_amd64', 'py35-none-win_amd64', 'py34-no
ne-win_amd64', 'py33-none-win_amd64', 'py32-none-win_amd64', 'py31-none-win_amd64', 'py30-none-win_amd64', 'cp39-none-any', 'py39-none-any', 'py3-none-any', 'py38-none-any', 'py37-none-any
', 'py36-none-any', 'py35-none-any', 'py34-none-any', 'py33-none-any', 'py32-none-any', 'py31-none-any', 'py30-none-any']
With, for example, "pyHook-1.5.1-cp36-cp36m-win32.whl", I could check the name and see if it's compatible or not (except because of the warning above...).
Any other ideas?
Thanks in advance for any help!
EDIT: I could go manually and pull things from the name and hard-code the some possibilities I see on documentation, like "win32" and "win_amd64" (as I did before), but then I'd need to know exactly all the possibilities that the parts of the name can have (I saw a cool expression on the documentation: "e.g." - which means there are more than the mentioned things) and have a lot of work on that. I was hoping there was already someone that had made such thing (maybe even Python itself has some way in any of its internal packages).
You can do this using packaging.
pip install packaging
An example code to get the tags similar to how you got from pip would be:
from packaging.tags import sys_tags
tags = sys_tags()
print([str(tag) for tag in tags])
# ['cp39-cp39-manylinux_2_33_x86_64', 'cp39-cp39-manylinux_2_32_x86_64', 'cp39-cp39-manylinux_2_31_x86_64', ..... , 'py31-none-any', 'py30-none-any']
Of course, you can do much more things programmatically with the above variable tags:
>>> tags = sys_tags()
>>> for tag in list(tags)[:3]:
... print(tag.interpreter, tag.abi, tag.platform)
...
cp39 cp39 manylinux_2_33_x86_64
cp39 cp39 manylinux_2_32_x86_64
cp39 cp39 manylinux_2_31_x86_64
For more in-depth documentation, check: https://packaging.pypa.io/en/latest/tags.html#packaging.tags.sys_tags
for my package, I have the following setup.py
import setuptools
setuptools.setup(
setup_requires=['pbr>=2.0.0'],
pbr=True
)
when I run python setup.py sdist, the version that gets tagged to the tar file is module-0.0.1.dev1207. If I modify the setup.cfg to have the following entry
[metadata]
version = 1.0.1
the version that gets tagged to the tar file is -1.0.1.dev1207.
I did some readings into pbr and saw that it uses the git commits and tags to create its versioning.
On their documentation, it states that
Versions can be managed two ways - postversioning and preversioning. Postversioning is the default, and preversioning is enabled by setting version in the setup.cfg metadata section. In both cases version strings are inferred from git.
If the currently checked out revision is tagged, that tag is used as the version.
If the currently checked out revision is not tagged, then we take the last tagged version number and increment it to get a minimum target version.
We then walk git history back to the last release. Within each commit we look for a Sem-Ver: pseudo header, and if found parse it looking for keywords. Unknown symbols are not an error (so that folk can’t wedge pbr or break their tree), but we will emit an info level warning message. Known symbols: feature, api-break, deprecation, bugfix. A missing Sem-Ver line is equivalent to Sem-Ver: bugfix. The bugfix symbol causes a patch level increment to the version. The feature and deprecation symbols cause a minor version increment. The api-break symbol causes a major version increment.
If postversioning is in use, we use the resulting version number as the target version.
If preversioning is in use we check that the version set in the metadata section of setup.cfg is greater than the version we infer using the above method. If the inferred version is greater than the preversioning value we raise an error, otherwise we use the version from setup.cfg as the target.
We then generate dev version strings based on the commits since the last release and include the current git sha to disambiguate multiple dev versions with the same number of commits since the release.
But that makes me unsure about the following questions:
How can I enable preversioning?
What if there was never a tag or in the repo since pbr seems to say that at least one of them is necessary for pbr to work correctly?
How can I remove the dev1207 part of my version?
How can I setup the setup.cfg to read the version from my main.py instead of me having to specify it in the setup.cfg file?
Preversioning and postversioning are enabled in PBR by default, and based on string semantics. More info on the latest SemVer versioning standard can be found here.
I think what you are looking for, though, is how to update the version from git. To do that simply add a tag with a SemVer string, for example v1.0.1 or even just 1.0.1. Other options - see SemVer documentation above.
PBR will use the latest tag it can find - I believe in the currently checked out branch. If it doesn't find a valid tag (which seems to be the case for your repo), it certainly appears to first default to 0.0.1, but also appears to revert to using the version string in the metadata in setup.cfg.
Once it has that version, if there are any commits made after the last tagged version, it appends a .devN postfix to the version string, incrementing it for every untagged commit.
So, I'm guessing you have a large master branch that has 1209 commits, but no tags? Something like that, anyway.
Just start tagging your commits when you have a release, or stick with the devN style releases. It's really up to you.
I'm using Windows 7, latest windows update etc.
Recently I decided to start using the minted package in LaTeX. For this, I was redirected to install pygments, which I installed through pip:
I'll run you through quickly what I did (to make sure I didn't do anything wrong):
Installed python 3.4 from this page.
easy_install pip in the windows command prompt.
pip install pygments in command prompt.
I've added the %PYTHONPATH% as well as %PYTHONPATH%\Scripts (which is where pygments operates from I've been led to believe), to the system PATH environment.
I'm typing source code from R into LaTeX, but the releases I could find do not offer the capital R syntax. If I use LaTeX code as such:
\documentclass{article}
\usepackage{minted}
\begin{document}
\begin{minted}{R} % Capital R won't function as intended with recent release
c(1,2,5,7,8)
\end{minted}
\end{document}
It won't recognise the capital R argument in minted.
Now, the lower case \begin{minted}{r} works just fine, so I've looked around on how to fix this, and found this answer.
Here it is suggested to adjust the math.py lexer (at %PYTHONPATH%\Lib\site-packages\pygments\lexers) to add an alias 'R' to current aliases. It also suggests to run _mapping.py in the same directory (%PYTHONPATH%\Lib\site-packages\pygments\lexers). Running _mapping.py has two effects:
It completely empties the file, the file size is reduced to 0 bytes and editing it with IDLE confirms an empty file.
It also yields this error message.
Not running _mapping.py won't apply my new alias to pygments. Running it, breaks pygments entirely. The error code is shown below.
I ran the LaTeX code again (with changes and _mapping.py also run), with pdfLaTeX, with arguments: $synctexoption, --enable-write18, -interaction=nonstopmode and $fullname (also in this order), I get the following error in LaTeX:
LaTeX Error: File `temp.out.pyg' not found.
Type X to quit or <RETURN> to proceed,
or enter new name. (Default extension: out.pyg)
Enter file name:
! Emergency stop.
<read *>
l.64 \end{minted}^^M
After running _mapping.py on a clean installation even (no changes made to any lexer or anything), I also run into the same problem. I'm uncertain whether the initial changes I made, changed registry values and whatnot, but I'm having serious issues applying this simple change to the pygments lexer.
Hi I'm having trouble installing and using the Mercurial ChartExtension
When I installed it as per instructions
First you need to install the extension; type this in your shell:
python ./setup.py install
Blockquote
I then modified my mercurial.ini file as follows
[extensions]
chart=/path/to/chart.py
Blockquote
Then tried running Hg Chart command and got the following error
Can anyone help me get this extension working. I know there's the Hg ActivityExtension as well, but i have not had much luck with that either Problem installing Mercurial Activity extension
A layman's guide to what steps i need to follow would be of immense help
Based on the changelog, the Chart extension has not been updated since late 2008. It would probably work if you tried using it with a version of Mercurial released around that same time (Mercurial v1.1.2 was released on Dec. 30, 2008).
The latest version of Mercurial is now v1.9.2. The API has changed (probably quite a bit) since v1.1.2. If the extension has not been modified to keep up with the changes to the API, then it will fail in ways similar to the error you found. In this case, the number of arguments for the walkchangerevs method has changed.
Updating the extension could be a large task...there is no way to know without inspecting the code. You could try to contact the author (#Ry4an) and ask for help. You could also try to modify the extension yourself.
I'm trying to install an egg on a computer where an identical egg already exists. Why does it remove the egg and then re-install it? I'm calling easy_install from a script with the options:
['-v', '-m', '-f', 'R:/OPTIONS/Stephen/python_eggs', 'mypkg==1.0_r2009_03_12']
While running the easy_install command this was observed:
Searching for mypkg==1.0-r2009-03-12
Best match: calyon 1.0-r2009-03-12
Processing calyon-1.0_r2009_03_12-py2.4-win32.egg
Removing d:\devtools\python24\lib\site-packages\mypkg-1.0_r2009_03_12-py2.4-win32.egg
Copying mypkg-1.0_r2009_03_12-py2.4-win32.egg to d:\devtools\python24\lib\site-packages
What causes this? Why is it that some times the egg is removed and re-installed, and on other occasions the egg is preserved? I've seen it happen a few times on my own PC but I'm not sure how to consistently re-produce the behavior.
I'm using setuptools 0.6c9
Here is what I am guessing is happening... This is a guess based on your description of the symptoms.
Assuming in your example mypkg and calyon are the same, the use of -r2009-03-12 on the end of your is not an expected format for setuptools (the standard format for post release tags is without hyphens YYYYMMDD) so it cannot ensure that the current version is up to date. Check out the links below and make sure you are versioning correctly.
Additionally, I believe easy_install manages its version info in the easy-install.pth file. What does your easy-install.pth file say about your package?
http://peak.telecommunity.com/DevCenter/setuptools#specifying-your-project-s-version
http://peak.telecommunity.com/DevCenter/setuptools#tagging-and-daily-build-or-snapshot-releases
It may show up on the bug list, otherwise it'd be best to report it.