In setup.py one can use the install_requires key to list mandatory dependencies of a package.
Is there a way to recommend the installation of other packages here, even if they are not required for the package to work?
I'm thinking about something similar to debian's apt which makes a distinction between these two cases.
Related
I have a Python library (https://github.com/jcrozum/PyStableMotifs) that I want to publish on PyPI. It depends on another library (https://github.com/hklarner/PyBoolNet) that I do not control and that is only available on GitHub, and in particular, it is not available on PyPI. My setup.py looks like this:
from setuptools import
setup(
... <other metadata> ...,
install_requires=[
'PyBoolNet # git+https://github.com/hklarner/PyBoolNet#2.3.0',
... <other packages> ...
]
)
Running pip install git+https://github.com/jcrozum/PyStableMotifs works perfectly, but I can't upload this to PyPI because of the following error from twine:
Invalid value for requires_dist. Error: Can't have direct dependency: 'PyBoolNet # git+https://github.com/hklarner/PyBoolNet#2.3.0'
My understanding is that direct links are forbidden by PyPI for security reasons. Nonetheless, PyBoolNet is a hard requirement for PyStableMotifs. What do I do? Give up on PyPI?
I just want pip install PyStableMotifs to work for my users. Ideally, this command should install the dependencies and I should not have to maintain two versions of setup.py.
Failing that, I have considered creating a "dummy" package on PyPI directing users to install using the command pip install git+https://github.com/jcrozum/PyStableMotifs. Is this a bad idea (or even possible)?
Are there already established best practices for this situation or other common workarounds?
EDIT:
For now, I have a clunky and totally unsatisfying workaround. I'm keeping two versions; a GitHub version that works perfectly, and a PyPI version that has the PyBoolNet requirement removed. If the user tries to import PyStableMotifs without PyBoolNet installed, an error message is shown that has install instructions for PyBoolNet. This is far from ideal in my mind, but it will have to do until I can find a better solution or until PyPI fixes this bug (or removes this feature, depending on who you ask).
My recommendation would be to get rid of the direct URL in install_requires, and tell your users where they can find that dependency PyBoolNet since it is not on PyPI. Don't force them on a specific installation method, but show them an example.
Maybe simply tell your users something like:
This project depends on PyBoolNet, which is not available on PyPI. One place where you can find it is at: https://github.com/hklarner/PyBoolNet.
One way to install PyStableMotifs as well as its dependency PyBoolNet is to run the following command:
python -m pip install 'git+https://github.com/hklarner/PyBoolNet#2.3.0#egg=PyBoolNet' PyStableMotifs
You could additionnally prepare a requirements.txt file and tell your users:
Install with the following command:
python -m pip install --requirement https://raw.githubusercontent.com/jcrozum/PyStableMotifs/master/requirements.txt
The content of requirements.txt could be something like:
git+https://github.com/hklarner/PyBoolNet#2.3.0#egg=PyBoolNet
PyStableMotifs
But in the end, you should really let your users choose how to install that dependency. Your project only need to declare that it depends on that library but not how to install it.
I'm quite experienced with ReactJS and now I'm trying to learn ReasonML. But one thing that I've been struggling to understand, is how to import npm packages with React/Reason.
The instructions on the website are kinda unclear to me (https://reasonml.github.io/guide/javascript/interop/).
So, if I have a React/Reason project and want to use a npm package, how do I do it? How do I import it, using Reason lang?
First off, thanks for the feedback! I'll make sure to get this improved.
Now, to be able to use a javascript library published on npm, you'll need to either find or make some bindings for it, as a bridge between Reason/BuckleScript and JavaScript. Ideally, the bindings you need have already been written (or generated) and published to npm, but in case it hasn't you'll have to write them yourself.
Most readily available bindings are listed in redex, the package index, and will include instructions on how to use it. But if they don't, all you need to do is run npm install --save <package-name>, as usual, then add the package name to the bs-dependencies array in bsconfig.json (see also the BuckleScript manual). Make sure to run bsb -make-world to get the new dependency built, then you should be able to use the modules exported by the bindings directly.
If there are no bindings, and you want to make your own, all you need to do is add the javascript package as normal using npm install --save <pacakge-name>, then just start writing externals. How to do so is described in the BuckleScript manual. You may also find my FFI cheatsheet useful.
Lastly, you're welcome to join us on our Discord where there's lots of friendly people eager to help!
When you create a Makefile.PL with Module::Install, you can define dependencies by using keywords like requires, test_requires, recommends and probably others. While installing a distribution based upon such a Makefile.PL, all dependencies marked as required are installed, but recommended ones are left uninstalled.
I noticed that there is a configuration option recommends_policy in newer versions of CPAN, that toggles whether to install recommended/optional packages or not. It is exactly providing the functionality I am searching for with this question.
To avoid editing my cpan configuration I would like to know, if it is possible to enable this functionality by using a command line parameter of cpan or a statement inside of my Makefile.PL that does the same, if one of the required dependencies of my distribution has recommended dependencies.
I didn't find an option in the cpan documentation, that answers my question and the documentation of recommends in Module::Install does not provide further information.
Googling the keywords just met so many different questions and answers, that I was not able to find the needle in the haystack.
p.s. I know that I could just require the packages in my own Makefile.PL, but then I would start to manage dependencies of external projects, which is an overhead, that I'd like to avoid.
edit: I am searching for something like
cpan --recommends_policy=1 Module::Name
This is not something that the cpan command does. I've thought about adding a switch to set single configuration options from the command line but I don't think many people will use it.
I use cpanminus to install Perl packages to userspace, but i have not found idiomatic way to maintain packages afterwards. How you update, delete (with dependencies) and get overview of listed packages?
You can use cpan-outdated. The man page has clear instructions for how to use with cpanminus.
After testing my Catalyst application and deciding to deploy it I would like to package it up so I can easily pull it in on the staging and live servers, manage dependencies and easily roll-back via the flexibility of package versioning. As my production OS is Ubuntu I figured packaging it as a deb package would make most sense.
I am predicting I will have to create a second package of all my perl module dependencies as many are not provided by my distribution, or package them independently - though that may be a lot of work.
Does anyone have any experience of doing this - or a sane, similar alternative?
To build your own Debian packages out of CPAN packages:
Install Debian helper scripts
sudo apt-get install dh-make-perl
Download MODULE from CPAN and build Debian package
cpan2deb MODULE
dh-make-perl is actually the right tool to put CPAN modules into Debian packages. Together with apt-file it can even prepare proper dependencies for you.
About being able to "easily roll-back" though requires special attention to versioning or workflows. There are several approaches that might get your job done here:
If you can force-downgrade packages you have won already most of the time unless you have very specific maintainer scripts that do jobs on package upgrades - then you will have to make them able to handle the downgrade, too
If you have to go the regular upgrade-path, using approaches like using "< newversion>+rollback< oldversion>" or similar might be something to consider.
Dependency-packages are always a good idea for deployments to make sure no required package actually is missing. Also, you might want to invest some time in management frameworks like puppet, they might come handy here, too.