Hi I have been trying to build a package which has...
# general
r
Hi I have been trying to build a package which has dependency on another package. Although I don’t see any files from the dependency. I have this toy repo where I am playing around with it. There are two packages:
package_a
and
package_b
,
package_a
has dependency on
package_b
I do see the
package_b
as dependency in generated
setup.py
. Is this how it’s supposed to work? The python_distribution for
package_a
is defined here and the repo
This is what I see locally when I unzip the generated dist
Copy code
tar -xvf dist/package_a-0.1.0.tar.gz -C ../unzip_dist
x package_a-0.1.0/
x package_a-0.1.0/MANIFEST.in
x package_a-0.1.0/PKG-INFO
x package_a-0.1.0/backend_shim.py
x package_a-0.1.0/package_a/
x package_a-0.1.0/package_a/__init__.py
x package_a-0.1.0/package_a/main.py
x package_a-0.1.0/package_a/package_a.py
x package_a-0.1.0/package_a.egg-info/
x package_a-0.1.0/package_a.egg-info/PKG-INFO
x package_a-0.1.0/package_a.egg-info/SOURCES.txt
x package_a-0.1.0/package_a.egg-info/dependency_links.txt
x package_a-0.1.0/package_a.egg-info/namespace_packages.txt
x package_a-0.1.0/package_a.egg-info/requires.txt
x package_a-0.1.0/package_a.egg-info/top_level.txt
x package_a-0.1.0/setup.cfg
x package_a-0.1.0/setup.py
h
Yeah, I think this is working as intended. How Pants decides which code goes in which distribution is explained here: https://www.pantsbuild.org/docs/python-distributions#mapping-source-files-to-distributions
But Pants goes to great lengths to not embed the same code in multiple distributions
so if package_a has a dist and package_b has a dist then pants will "do the right thing" by default and build a package_a dist with a requirement on package_b's dist
r
So in this case it means I need to make sure pants can access the
package_b
as 3rd party dependency when installing
package_a
right?
h
Not sure what you mean exactly. Pants should be able to build a distribution from
package_b
, I assume it has a
python_distribution
target?
So the thing is that you have to publish
package_b
so that
package_a
can consume it
This is the downside of using publishing as your dependency mechanism. The alternative is PEX files, where package_a and all its deps (including package_b) get bundled into a single file.
👍 1
r
yeah I meant the publishing aspect. So that clears it. Yeah I do think PEX is the way to go.
h
Since pexes aren't consumed by other code, it is safe for them to bundle all the deps, even if multiple pexes have overlapping code, as there will not be ambiguity about where a symbol should come from (it comes from inside the pex!)
So they really are a great way to package and deploy code that isn't intended to be published and then consumed by others