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

Make configobj a package, moving towards incorporating validate #32

Closed
robdennis opened this issue Feb 27, 2014 · 4 comments
Closed

Make configobj a package, moving towards incorporating validate #32

robdennis opened this issue Feb 27, 2014 · 4 comments

Comments

@robdennis
Copy link
Member

Coming out of the discussion from #31, it's important to understand where we see validate fitting in long term. I think this post does a good job of marking this out:

  1. Make configobj a package instead of a single configobj.py file, and put validate.py inside of it. Make a separate top-level validate model that raises PendingDeprecationWarning when imported, but otherwise just works as expected. Update the documentation to tell people to do this the correct way, with a note that validate.py used to be a top-level module and is now deprecated. This step can probably come in a later 5.x release.
  2. In a later release, keep this exactly the same, except that we'll raise DeprecationWarning instead of PendingDeprecationWarning. This would probably happen in a 6.0 release.
  3. Remove validate.py altogether, after the deprecation warnings have been there for awhile. I'm not super concerned about this step, and IMO there should be at least a year between Step 1 and this step to give people who are not pinning their dependency versions (shame on them) time to update their code.

This is something to consider in a 5.1.x release

@robdennis robdennis added this to the 5.1.0 - next backwards-compatible release milestone Feb 27, 2014
jhermann added a commit to jhermann/configobj that referenced this issue Apr 11, 2015
* handles DiffSK#72
* handles DiffSK#31
* handles the core of DiffSK#32
* using ImportWarning as appropriate for an import change
* tox passing for py27, i.e. structurally sound
* the shim should probably released one final time as
  'validate' to PyPI
@jhermann
Copy link
Collaborator

Please use "?w=1" on commit diffs, my editor is set to canonize away redundant trailing whitespace.

@jhermann
Copy link
Collaborator

Why a "src" directory? See e.g. http://blog.ionelmc.ro/2014/05/25/python-packaging/#the-structure

The "tests" dir could be moved down there, too. Which then eases targeted recursive greps and such things. 😉

@EliAndrewC
Copy link
Member

(Apologies for the delay, I've been slammed recently with a combination of work and personal projects.)

I originally was going to argue against the use of a src/ directory, but I find the linked article very persuasive, especially points 1, 3, and 4. The rest of the points I'm pretty "meh" on and/or outright disagree with, but the points I do agree with outweigh the others, at least in this case :)

I like what I'm seeing. I checked out the code and poked around and ran tox myself as a sanity check and everything seems good.

I'm going to hold off on accepting the PR for right now because there's another outstanding pull requests which I've been slacking on confirming which was opened first and they might conflict. Either way I hope to have them both handled by the end of this week.

@jhermann
Copy link
Collaborator

Fixed a while ago.

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

No branches or pull requests

3 participants