Closed jorgeorpinel closed 3 years ago
get-started-experiments is an autogenerated repo. Please create ticket in the main dev repo which generates all of these.
I spoke about that earlier with @iesahin and we agreed it was OK to open issues directly in the generated repos, as users would do (you can't disable the issues section so it's hard to enforce this). Maybe the generator repo can even be private.
But OK I can easily transfer this over ✔️
I think it's fine to transfer if someone creates them.
We don't want to rely on those repos to be persistent in any way. Or at least less we rely on that - better for us.
Ah, do issues get wiped when you re-generate them? Yeah that would be a problem.
@jorgeorpinel even if they don't we might decide to delete and create that repo again. I think every feature of those repos should be codified and auto-generated for simplicity. They are not done to iterate on them directly in any way.
You're using Python 3.6 (and pip
seems very old.) Tensorflow is very sensitive to Python versions, @shcheklein couldn't run an earlier version of the repo (using TF 2.4.1) in Python 3.9 and dependabot alarmed me to upgrade the requirements to TF 2.5 when it was released. Now we can run this version in Python 3.9 but can't run in 3.6, it seems.
I can remove the version requirements and let pip
pick whichever version is available. We don't use cutting-edge TF features, so it shouldn't matter but I'm ambivalent on this. It doesn't look like a good practice.
@jorgeorpinel
even if they don't we might decide to delete and create that repo again. I think every feature of those repos should be codified and auto-generated for simplicity.
On one hand we can just delete the repo, but on the other I think it's better for users to create issues directly in the repo for context. example-repos-dev
has a very different structure and creates more than one repository and asking users to report errors there may be too much. Issues are mainly a feedback mechanism, I think we shouldn't frighten the users by asking them to create the issue in a different place.
Also there is no 1-1 correspondence with the files in example-repos-dev
and get-started-experiments
(or any other example repository.) We use dvc stage add
commands to create dvc.yaml
file, or dvc import
the data. A user must be savvy enough to report an error in example-repos-dev
in the first place.
and pip seems very old
Weird, Idk why pip
there was 9. It's 21 now and I get the same error.
Now we can run this version in Python 3.9 but can't run in 3.6, it seems.
That would be a problem according to Google,
but actually it's working now. Strange, I didn't change anything. Both times run in a fresh virtualenv
¯_(ツ)_/¯
we might decide to delete and create that repo again
on the other I think it's better for users to create issues directly in the repo for context Also there is no 1-1 correspondence with the files in example-repos-dev and get-started-experiments
It's an interesting Q but TBH we don't have this problem (yet). Let's wait until when/if users report significant issues for these repos before optimizing, I guess.
we shouldn't frighten the users by asking them to create the issue in a different place
We'd just transfer the issues ourselves for now.
Both times run in a fresh virtualenv
Ah! I found the culprit. It's the way venv
is recommended in the README:
$ python -m venv .venv
$ . .venv/bin/activate
$ pip -V
pip 9.0.1 from /.../.venv/lib/python3.6/site-packages (python 3.6)
I used that originally. The 2nd time I did
$ virtualenv .venv
System virtualenv
which I think I installed with global pip install
(probably --user
).
Ah, then, that's a good data point for #26. If python -m venv
doesn't run as expected, we shouldn't use it. Thank you @jorgeorpinel
I'm now using virtualenv
in #2574 and will continue to do so in the newer docs. I thin we can close this now.
I'm on Ubuntu 20.04 LTS on WSL 2