Closed billglover closed 4 years ago
Newb question: did you run docker exec
to get into the app before you ran pip3 install -r /opt/cbv3_django_prototype/requirements/local.txt
? (Still trying to figure out how to install specific packages with docker running now that I'm not running local virtualenvs)
Nope, I used docker-compose up --build
. I took the command above from the start-up logs during package installation.
So..I have a really stupid question. I am using the fixtures right now to populate my database, and so I end up with 21 users, 31 Resources and 237 assorted tags. Is that not sufficient for a staging deploy?? Do we need more data than that? Just wondering why you want Faker (and its associated problems) in the mix.
Not that it isn't a good idea to have test data generation...not by a long shot. Just that we do have a small set of working data atm.
I’m not sure what faker is. If we can remove it and reduce dependency count I’m all for that.
This error has been there since the beginning only now got round to raising it.
Faker is a python library that generates "fake" data of specific types (e.g. names, addresses, phone numbers) from a small set of seed data that it comes packaged with.
It is evidently a dependency of factory-boy, a dango-python library used to create testing fixtures dynamically.
I hate nested dependancies The ultimate culprit is python-slugify
, which is pinned at version 3.0.3
, (which uses text-unidecode 1.2.) . But Faker uses text-unidecode 1.3, hence the error message. The reason the whole install didn't explode is that factory-boy falls back to an earlier version which then "fixes" the compatibility problem, but leaves the original error logged.
Bumping the version to python-slugify==4.0.0
, which uses text-unidecode 1.3 appears to fix the issue (and then factory-boy and Faker can install with later versions), and has not caused any obvious problems I can see.
Emphasis on that I can see.
I'm going to make the change in my base.txt
, and keep my fingers crossed that nothing will explode. What an annoying experience!!
@BethanyG Nice sleuthing!
Do we have an easy way to look at the dependency tree? I'd like to be able to:
I haven't tested out all of these...it's a process. But I did want to note what I dug up here so you could explore as well. This Blog Post by Hynek Schlawack was a place I started to get some lay of the land. It's highly opinionated, of course. The post by Nick Timkovic - recommended by @chris48 in Slack was also informative.
pip-tools
(as recommended in the above blog post). Does attempt to check off points one and three, but doesn't clean the tree - nor let you see the tree, for that matter.
pipdeptree
current build is broken, but this still looks intriguing. At least we could run it and see our tree. Some notes I found on it.
pipreqs
designed to generate requirements.txt
files based on imports in a project, rather than installed packages. Might be worth a shot to diff our requirements.txt
files against this and see which is smaller...
pip-autoremove
removes a package and any of its unused dependancies.
Wrong direction here..but pip_check_reqs
will check for modules that you should include at the top level that were only included because of a dependancy.
poetry as a tool to make it "easier" to manage all this. But yes - another tool and another dependency itself.
hatch but really? They are trying to make a different version of Cookiecutter with venvs so probably not wanted here.
@billglover - as soon as I am done with my tagging PR (next day or so), I will get on trying out some tools.
Some things here:
python-slugify
, but I will open a new bug about dependency management/tools. (this is now bug #97)Faker
is even something we want to deal with, given our context. If the answer is no, we can get rid of this particular package/hassle altogether.
Run the following command to install development packages:
During package installation the following error is returned:
Expected behaviour: no errors or warning shown during package installation.