Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update dependency to use our fork of odfpy. #343

Merged
merged 1 commit into from
Dec 6, 2017
Merged

Update dependency to use our fork of odfpy. #343

merged 1 commit into from
Dec 6, 2017

Conversation

galund
Copy link
Contributor

@galund galund commented Dec 5, 2017

  • this is to fix a bug in the odfpy library where it can produce non-well-formed XML.

  • note that in order for this requirement to be satisfied you will have to manually update your requirements files to include the location of the forked library.

https://trello.com/c/EgBoNeW9/145-certain-control-characters-in-suppliers-evidence-corrupts-the-ods-that-buyers-download

** We may not want to land this change **

[We decided to land this change nonetheless.]

Reasons to not land this change:

  • it's actually a breaking change. When we attempt to bring this version of dm-utils into a frontend, we will find we can't actually install it until the relevant requirements-app.txt is updated and the requirements.txt is rebuilt.

  • Once you realise you have to update the requirements.txt, there are two options: include the deprecated "--process-dependency-links" flag, or copy in the full git repo details to allow pip to find our new version of odfpy. I think I prefer the latter - adding to the number of warnings doesn't seem ideal.

  • There's an alternative: we can just change the setup.py here to allow a range (e.g >1.3.6), and then add the repo details into the frontend app(s) requirements.txt files necessary. If we're going to do that anyway, why bother making an incompatible version of dm-utils at all?

ISTM that the alternative approach fits with what seems to pass for current pip 'philosophy', which is that libraries should use setup.py only to declare which versions of their dependencies they are API-compatible with. And then it's (apparently) supposed to be up to people writing applications to pull all of these things together into sensible sets of dependencies (and sources) that are then expressed in a requirements.txt file. There's some flaws in that in terms of usability, but that's my understanding - can share references if anyone really wants.

 - this is to fix a bug in the odfpy library where it can
   produce non-well-formed XML;

 - note that in order for this requirement to be satisfied, you
   will have to update your requirements[-app].txt to include
   the new dependency;

 - we are avoiding using "dependency-links" in setup.py, because
   pip's support for that (i.e. via the `--process-dependency-links`
   option) is deprecated and has already disappeared once. (See
   <https://github.com/pypa/pip/pull/1955/files>.

https://trello.com/c/EgBoNeW9/145-certain-control-characters-in-suppliers-evidence-corrupts-the-ods-that-buyers-download
@galund
Copy link
Contributor Author

galund commented Dec 6, 2017

Okay, have rewritten this to remove the "dependency-links" thing, in favour of an approach that mirrors what we expect users of dm-utils to do, i.e. update requirements.txt.

@galund galund merged commit 17b7b83 into master Dec 6, 2017
@galund galund deleted the update-odfpy branch December 6, 2017 17:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants