Reputation: 3299
I have two python packages A
and B
that I would like to merge together into A
, i.e. all functionality of B
is now reachable in A.B
. Previously, A-1.0
depended on B-1.0
. Now I want to avoid, that users of A-2.0
still have B-1.0
installed and I don't know how to handle this properly.
Different solutions/ideas I came up with:
Include some code in A-2.0
that tries to import B
, if an ImportError is raised, catch the exception and go on, otherwise throw a RuntimeError that B
is installed in parallel
Somehow mark B
as a blocker for A-2.0
(is this possible?)
Create a "fake" successor for B
, so people who update their virtual environments or install the "latest" version of B
get an empty package that throws an exception upon importing.
I welcome your opinion, and experiences
Upvotes: 4
Views: 2282
Reputation: 12728
I think, you can't! (at least without using such tricks, as you described).
The Python package system has (to my knowledge) no such notion as "allowed" packages. There could be a person, that invents a different package C that he calls B, but with totally different functionality. Such a notion would prohibit users of your package A to use package C (alias B).
So I would communicate to users of A, that B is no longer needed and make sure, that your newer coding does not reference B at all. And when somebody installs B, it is like a third party library that has nothing to do with yours.
Of course, when the functionality of A and B is intermingled very much and the other user code also has to deal with B directly and has (allowed) side effects on A, you could get in trouble when an old B is still installed. But than your initial design was not the best either.
In such a case (and when you really have to merge the packages -- see below) I would recommend, that you make a totally new package name like "newA" to underscore the fact, that something has fundamentally changed (and thus an intermingling between old A and B also would more likely be detected).
But of course, I would second the argument of msw, that you create your problem by yourself. Normally it is also better to have smaller packages (if they are of a reasonable size, of course) instead of bigger "I manage the world" packages. You just can combine smaller packages better for different applications.
Upvotes: 1