I'm building a complex set of Python / PyPI packages and modules.
I would like to have modules hello.a, hello.b and hello.b.c respectively in packages hello-a, hello-b and hello-b-c. Package hello-b-c would depend on hello-b.
Is it possible? Would you suggest a different setup?
Related
Pip supports the pyproject.toml file but so far all practical usage of the new schema requires a 3rd party tool that auto-generates these files (e.g., poetry and pip). Unlike setup.py which is already human-writeable, pyproject.toml is not (yet).
From setuptools docs,
[build-system]
requires = [
"setuptools >= 40.9.0",
"wheel",
]
build-backend = "setuptools.build_meta"
However, this file does not include package dependencies (as outlined in PEP 621). Pip does support installing packages using pyproject.toml but nowhere does pep specify how to write package dependencies in pyproject.toml for the official build system setuptools.
How do I write package dependencies in pyproject.toml?
Related StackOverflow Questions:
How to init the pyproject.toml file
This question asks for a method to auto-generate pyproject.toml, my question differ because I ask for a human-written pyproject.toml.
my question differ because I ask for a human-written pyproject.toml
First, the pyproject.toml file is always "human-writable".
Then, it is important to know that in this context setuptools and Poetry take the role of what are called "PEP 517 build back-ends", and there are many such back-ends available today, setuptools and Poetry are just two examples of them.
As of today, it seems like most (if not all) of the build back-ends I know of expect their configuration (including dependencies) to be written in pyproject.toml.
PEP 621
There is a standard called PEP 621 that specifies how a project's metadata, including dependencies, should be laid out in the pyproject.toml file.
Here is a list of build back-ends I know of that have support for PEP 621:
enscons
flit_core (see flit)
hatchling (see hatch)
pdm-pep517 (see pdm)
setuptools (experimental support since version 61.0.0)
trampolim
whey
For all PEP 621 compatible build back-ends, the dependencies should be written in pyproject.toml file like in the following:
[project]
name = "Thing"
version = "1.2.3"
# ...
dependencies = [
"SomeLibrary ~= 2.2",
]
References:
https://peps.python.org/pep-0621/
https://setuptools.pypa.io/en/latest/userguide/pyproject_config.html (experimental support for PEP 621 has been added to setuptools version 61.0.0, released 2022-03-24)
setuptools (before version 61.0.0)
In setuptools before version 61.0.0 there is no support for writing the configuration in pyproject.toml (in other words: no PEP 621 support). You have to either write a setup.cfg, or a setup.py, or a combination of both.
My recommendation is to write as much as possible in setup.cfg. Such a setup.cfg could look like this:
[metadata]
name = Thing
version = 1.2.3
[options]
install_requires =
SomeLibrary ~= 2.2
packages = find:
and in most cases the setup.py can be omitted completely or it can be as short as:
import setuptools
setuptools.setup()
References about the dependencies specifically:
https://setuptools.readthedocs.io/en/latest/userguide/dependency_management.html
https://www.python.org/dev/peps/pep-0508/
https://www.python.org/dev/peps/pep-0440/
Again, note that in most cases it is possible to omit the setup.py file entirely, one of the conditions is that the setup.cfg file and a pyproject.toml file are present and contain all the necessary information. Here is an example of pyproject.toml that works well for a setuptools build backend:
[build-system]
build-backend = 'setuptools.build_meta'
requires = [
'setuptools >= 43.0.0',
]
poetry
In poetry everything is defined in pyproject.toml, but it uses poetry-specific sections. In other words, Poetry does not currently use the PEP 621 standard, but there are some plans to move to this standard in the future.
This file can be hand-written. As far as I can tell, there is no strict need to ever explicitly install poetry itself (commands such as pip install and pip wheel can get you far enough).
The pyproject.toml file can be as simple as:
[tool.poetry]
name = 'Thing'
version = '1.2.3'
[tool.poetry.dependencies]
python = '^3.6'
SomeLibrary = '~2.2'
[build-system]
requires = ['poetry-core~=1.0']
build-backend = 'poetry.core.masonry.api'
References:
https://python-poetry.org/docs/pyproject/
https://python-poetry.org/docs/dependency-specification/
I have a project that I plan on developing in modules, the final application will be any number of the modules built together based on a configuration. I have a swift package that has all of my common code it it, we can call that the platform package. I then went to create my first feature, this went just fine however when I created the wrapper application to pull in each feature, I got this error from SPM in xcode11:
package 'Platform' is required using a revision-based requirement and it depends on local package
'Feature1', which is not supported.
Looking at the code base for SPM here (line 72)
https://github.com/apple/swift-package-manager/blob/master/Sources/PackageGraph/DependencyResolver.swift
It looks like this is something that is just not supported, the mixing of local and remote dependencies? Is this a limitation of SPM / should I be trying to use another tool for this type of app architecture?
In my case, I was trying to add a package, which I was developing, and its Package.swift contained dependencies of the form:
dependencies: [
.package(path: "../PackageName"),
// etc
Changing the references to specific repos solved the problem:
dependencies: [
.package(path: "http://github.com/..."),
// etc
I developed a nuget package "nuget_X" installed on a project "project_1".
I have a second project "project_2" that reference "project_1".
If "project_1" is published as nuget package "nuget_1", I can force "project_2" to reference "nuget_X" by declaring "nuget_X" as dependency of "nuget_1"
But "project_1" is referenced as "ProjectReference". So, how can I configure "nuget_X" or "project_1" to force "project_2" to install "nuget_X"?
PackageReference on Visual Studio 2017 don't allow to force nuget of dependency to be installed when using ProjectReference. But it allow to produce an acceptable equivalent result. for more details, see comments.
Let's assume there is a distribution "Example" that is packed in example-1.0.tar.gz which contains a Makefile.PL that points to all dependencies. After extracting, "Example" could be easily installed (including all its dependencies) by calling cpanm . if all its dependencies were available on CPAN.
How do I install a simialar file (let's call it example-2.0.tar.gz) if I am given a folder "deps" containing most of the distribution's dependencies
dependency-1.tar.gz
dependency-2.tar.gz
...
dependency-N.tar.gz
where N is a huge number?
Further assumptions are:
dependency-*tar.gz files have to be preferred over the available CPAN modules
some dependencies are not available on CPAN but only in this "deps" folder
the folder "deps" is incomplete and further dependencies have to be installed from CPAN.
Is there a simple way to install example-2.0.tar.gz?
I would like to know if there is some command line like cpanm --use-local-deps=~/deps example-2.0.tar.gz which does not need further workarounds.
You could use this tool http://search.cpan.org/~bingos/CPANPLUS-0.9152/bin/cpan2dist . It lets you specify filters to define what modules are loaded locally and what is fetched from CPAN. It's part of the CPANPLUS module, which should cone with newer versions of Perl I think.
Example:
Nuget package A is a set of code snippets (it does not contain an assembly).
Nuget package B is a normal assembly and it is using package A - just for internal means.
Question: What can I do, to avoid, that package A is also installed, when somone installes package B?
Found something in documentation of nuget:
Starting from version 2.7, the pack command will ignore entries in the packages.config file which have an attribute developmentDependency set to true and will not include that package as a dependency in the created package. For example, consider the following packages.config file in the source project
That seems to solve the problem.