Repository navigation
how to proceed to clean the hardcoded logilab-common files from this project? #932
Description
I see that ./pymode/libs/logilab-common-1.4.1 is still a "hard-coded" file in our project.
I think it should be moved out to ./submodules as other third party projects. This helps to clean this project so our contributors can focus on actual issues. The complication is that logilab-common is not a git maintained project:
Thus a different installation approach may be needed.
I thought about creating a ./makefile for some common operations in this project (including bug reporting: e.g.: cleaning .pyc files):
-
Pro: easy, clean, well understood and would help integrate non git projects into the installation procedure.
pythonis our friend here: just download the.tar.gzfrom a fixed location and extract it into./submodules. -
Con: Windows would be one step further away from being supported again in the future (because installation would depend on the
./makefile.
What do you think?
Activity
diraol commentedon Aug 8, 2018
@fmv1992 what about doing:
pip install -U logilab-common -t submodules/logilab-common; orpip install -U logilab-common -t vendor/logilab-common; orpip install -U logilab-common -t external/logilab-common.We can still version it on our repo, but as it is installed by pip, not the "copied source code" itself. Then it would be easier to "update it". And by versioning it we won't have to handle the installation problem.
Although I don't think that creating a Makefile is that bad.
Would you have some time to create this makefile? (I personally don't think I can handle it right now)
Can we do an intermediate step using "pip install .." for now and then moving to the makefile if you don't have time now?
fmv1992 commentedon Aug 11, 2018
@diraol,
Thanks for all the contributions you have made for this repo.
I like your idea; lets install it with
pip installwithout admin rights (I'll find the right flags for this). Just to be sure if I got it right: in this scenario nologilabfiles would be versioned within our repo (question 01).I think this
logilabthing would be the only exception to our "single-clone-get-everything-working" procedure. I'm not sure if this single exception is enough to call for amakefile. On the other hand having amakefilewould make it easier for us to automate some things, such asmake update(that would be agit pulland thelogilabupdate), tests, etc. Can you think of a more simple/elegant/convenient solution or shall we go with make? (question 02)I'll start working on this tomorrow; I'll have it commited by Sunday.
diraol commentedon Aug 11, 2018
Hi @fmv1992 ! =)
It is a pleasure to contribute to the project!
Regarding the issue itself, my first idea for a faster solution approach is to version the files, not requiring our users to have to run extra non-git commands to install the project.
But I do agree with you that a Makefile would make our life much much easier.
If we go with a Makefile approach, I think we may even stop using "versioned submodules" to go with a more "on-the-fly" installation.
I mean we can clone the repos we want and get the latest tag/version/master while installing the project (
make installor something like that). Then we won't necessarily need to update our repo to get the latest version of our dependencies. We will just need to do apip installfor each one of them.Seems a really nice idea!
I think I can give you a help with this issue today. =)
Then we can add much more commands to the makefile (update, test, etc).
stale commentedon Jan 8, 2019
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
diraol commentedon Jan 9, 2019
Keeping this issue active because I think it is still relevant.
stale commentedon Jun 8, 2019
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
diraol commentedon Jun 8, 2019
Ping .... one day I'll be back to this...
stale commentedon Nov 5, 2019
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
stale commentedon Nov 26, 2019
Closed due to inactivity.
diraol commentedon Dec 15, 2019
Resolved here: #1054