Faker package installation error

[billglover]

Run the following command to install development packages:

pip3 install -r /opt/cbv3_django_prototype/requirements/local.txt

During package installation the following error is returned:

ERROR: faker 4.0.1 has requirement text-unidecode==1.3, but you'll have text-unidecode 1.2 which is incompatible.

Expected behaviour: no errors or warning shown during package installation.

[lpatmo]

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)

[billglover]

Nope, I used docker-compose up --build. I took the command above from the start-up logs during package installation.

[BethanyG]

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.

[BethanyG]

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.

[billglover]

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.

[BethanyG]

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!!

[lpatmo]

@BethanyG Nice sleuthing!

[billglover]

Do we have an easy way to look at the dependency tree? I'd like to be able to:

• identify dependencies that have new versions available
• identify unused dependencies and remove them
• identify dependency conflicts at the time they are introduced

[BethanyG]

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.

1. 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.

2. 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.

3. 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...

4. pip-autoremove removes a package and any of its unused dependancies.

5. 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.

6. poetry as a tool to make it "easier" to manage all this. But yes - another tool and another dependency itself.

7. hatch but really? They are trying to make a different version of Cookiecutter with venvs so probably not wanted here.

[BethanyG]

@billglover - as soon as I am done with my tagging PR (next day or so), I will get on trying out some tools.

[BethanyG]

Some things here:

1. Exploring tools for dependency management is on my "next things" list.
2. This bug will be "fixed" in the tagging PR Taggingfixes 71 74 86 ..and 78 #96 by bumping the version of python-slugify, but I will open a new bug about dependency management/tools. (this is now bug [Tooling] Looking at & Managing the Project Dependency Tree #97)
3. Testing infrastructure is also on my "next things" list, and I will be assessing if 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.