I have a package I just updated to use setuptools_scm and found the version number is wrong in readthedocs.
http://sshuttle.readthedocs.org/en/v0.77/ shows:
Version: 0.78.dev0+ng083293e.d20160304
however as version 083293e has the 0.77 tag, the version string should be just 0.77
It looks like readthedocs might be making changes to my source code before building.
I have looked at the readthedocs build logs, and it seems to have the correct version at one stage (0.77), however this is before it builds the documentation.
Processing dependencies for sshuttle==0.77
Finished processing dependencies for sshuttle==0.77
The build logs don't mention the version while building the documentation.
Is it possible to solve this?
Thanks
I see that you're building this project.
Clearly, something is mutating the repository state before the version is determined. You can replicate similar behavior by mutating one of the files prior to building the docs yourself:
(sshuttle) $ python setup.py --version
0.77
(sshuttle) $ cat >> setup.py
# a comment
(sshuttle) $ python setup.py --version
0.78.dev0+ng083293e.d20160403
In the read the docs docs, there's a description of the process.
There, you can see the steps RTD does, namely, (a) run setup.py install then (b) install requirements in requirements.txt.
I've confirmed that neither of those steps should be mutating the repo state.
What it doesn't explain, however, is where that 'version' comes from, or what update_imported_docs does. I suspect the issue lies in something subtle that read the docs is doing that modifies the repo.
Here's one place where the conf.py file gets modified.
Perhaps adding docs/conf.py to your .gitignore will allow those changes to be ignored and thus not dirty your working state when calculating the project version.
https://github.com/pypa/setuptools_scm/issues/84 has been updated to record this
we will be working with the sphinx team to provide a automated/painless version of this process
The documentation for setuptools_scm now has instructions on how to use with readthedocs:
It is discouraged to use setuptools_scm from sphinx itself, instead
use pkg_resources after editable/real installation:
from pkg_resources import get_distribution
release = get_distribution('myproject').version
# for example take major/minor
version = '.'.join(release.split('.')[:2])
The underlying reason is, that
services like readthedocs sometimes change the workingdirectory for
good reasons and using the installed metadata prevents using needless
volatile data there.
This avoids the need to use kluges as per the other answer.
Related
This question is somewhat similar to the one here, but I cannot make it work.
So suppose that I have a set of packages (say 2) to install and I want to use pipenv. If I do pipenv install on the directory with a suitable Pipfile the installation fails because there is some metadata issue when installing one of the libraries (say libX) contained in install_requirements of one of the packages. It seems that the problem can be fixed by downgrading the version of setuptools to <=58.0.0.
OK. Now, if I first install that version of setuptools<=58.0.0 in the venv and then install my packages, everything works fine. The issue is that the Pipenvfile does not respect the order when installing, so something like
[packages]
setuptools = "<=58.0.0"
pckg1 = {<github path 1>}
pckg2 = {<github path 2>}
is not ensured to work. Also, by default the seed packages added to the venv include setuptools==65.6.3.
So the idea is to be able to restrict the version of setuptools that is used to check the metadata of the libraries in libX, to mimic the above scenario in which setuptools was installed first. Is there a way to do that?
I have tried placing setuptools<=58.0.0 at the top of the requirements.txt that defines the install_requirements of the problematic package, but it does not work.
If have also tried to fix or restrict the version of libX contained in that requirements.txt file but, surprisingly, pipenvdoes not seem to care: a verbose install shows that it keeps downgrading libX well below the restriction - "using cached libX-vX.X.X"- until it uses a version for which the metadata generation fails (why on earth does it do that, even if I call it with pipenv --clear install?).
I am a bit lost about what could be the best solution here. Any help would be very appreciated.
Is there a way to install multiple versions of the same package in CentOS/RHEL (7/8) if the package installs separate files in each version?
We have an application we've recently converted to using RPM instead of a home-built package manager based on tar. In order to make atomic-like switches between versions, each version installed in separate directories with the version number in the name, and a symlink with the unversioned name pointed to the current, or previous, version at any given moment in time. The application, of course, used the unversioned name to get init script, configuration files, interpreter version and code. I'm thinking that the alternatives package would be the basis for this, although we wouldn't use the alternatives command to manage symlinks (although there's no technical reason not to).
Not exactly as you describe.
Some packages allow this (Kernel and Kernel-devel being two of them) but i beilieve this is an exception added within the package manager.
Certain Applications like PHP and Python which is perfectly acceptable to have multiple version (Python2.X and 3.X) do this by changing the base name of the application/rpm.
Take a look at: https://rpm.org/user_doc/multiple_versions.html
It gives a good insight on how to achieve what you want
I can't seem to find anything useful in the man pages etc for this, but it seems like it should be straightforward..?
Our servers are running CentOS 6.8 but also have the Atomic repository for some package versions. The most recent version of one of the packages that Atomic provides seems to be broken, so we've had to do a yum downgrade of that package.
Problem now is that we're running Plesk, which performs automatic Yum updates on a schedule, and the next time this happens, the broken package will just drag back in again!
All I want to do is tell Yum to ignore this specific package version so that it updates the next time there's a newer version, but skips the current.
I found that I can add exclude= lines to yum.conf but I can't seem to find how to define a specific version number in this exclude. It looks like I can only exclude entire package names?
I'm more familiar with Gentoo where we can tell Portage to mask specific versions when problems like this occur. Is this not an option in CentOS?
Much appreciated.
I have gone through the following steps:
$ mkdir mongoEg
$ cd mongoEg
$ cabal init
...
Configured to run as an executable. I add mongodb to the build-depends list. I make a dummy Main.hs file and put a basic hello world in there. I then do
$ cabal sandbox init
$ cabal install --only-dependencies
Which responds with:
Resolving dependencies...
cabal: Could not resolve dependencies:
trying: monogEg-0.1.0.0 (user goal)
next goal: mongodb (dependency of monogEg-0.1.0.0)
Dependency tree exhaustively searched.
Note: when using a sandbox, all packages are required to have consistent
dependencies. Try reinstalling/unregistering the offending packages or
recreating the sandbox.
I read up on other problems people are having, and remove ~/.ghc, remove my mongoEg directory, and repeat to get the same results. I try to run through the analogous steps at http://howistart.org/posts/haskell/1 and find that everything works just fine.
I then guess that something is wrong with the mongodb package itself. I seem to be able to cabal install mongodb in a global environment and use it outside of a sandbox without any issue. So, why wont cabal sandboxes play with the mongodb package?
See this gist for details: https://gist.github.com/anonymous/e5a548cf7d9ec59bea31
After looking here
Cabal configure in a sandbox complains "At least the following dependencies are missing" on installed packages
I saw that the answer states that package names are case sensitive. So I tried changing mongodb to the way MongoDB spells it, namely MongoDB. This did not work, so I tried changing it to mongoDB, and finally there was joy.
So even though I can do cabal install mongodb I can't use that same spelling to install it from within a .cabal file, which is, obviously, completely stupid. I'm sure I'll find the right place to channel my rage about this kind of flagrant violation of the principle of least surprise, but for now I can say that to newcomers it is most needlessly confusing.
I'm new to python and it was recommended that I use Canopy. I'm trying to follow along with this tutorial, but I get stuck at the mahotas.imread line. I get an error saying that ends with this:
Full error was: mahotas.freeimage: could not find libFreeImage in any
of the following directories:
'/Users/RJD/Library/Enthought/Canopy_32bit/User/lib/python2.7/site-packages/mahotas',
'/lib', '/usr/lib', '/usr/local/lib', '/opt/local/lib'
I've added the mahotas package via the package manager to no avail. Also tried the steps here, with no different result.
I am actually able to find 'freeimage.py' and 'freeimage.pyc' in '/Users/RJD/Library/Enthought/Canopy_32bit/User/lib/python2.7/site-packages/mahotas'. How do I go about telling Canopy that it is there?!
Any help would be very much appreciated.
Cheers,
R
Author of mahotas here:
Mahotas itself does not have the functionality to read in images. imread is just a wrapper around one of 3 backends:
mahotas-imread (i.e., https://pypi.python.org/pypi/imread)
FreeImage (this was the original version and if you have such an old version [0.7.1 is from Jan '12], it might still only support FreeImage)
matplotlib (which only supports PNG & JPEG)
Thus, you need to install one of the packages above.
To be clear, there is no "enthought mahotas". Mahotas is not in the Enthought package repository but in our "Community" (PyPi mirror) repo of 11,000 untested ("as is") packages, as you can see by the "PyPI" logo in the Package Manager (sorry, that's not at all obvious, we'll fix this!) We will be updating this repo later this year. The version of mahotas in that PyPI repo is 0.7.1, whereas the current version of mahotas on PyPI is 1.0.2. So that avenue is not useful for now.
When you say that you tried the steps in the cmu.edu document, was that after uninstalling the old PyPI version just mentioned and going through each step mentioned in that document?