|
From: L. C. <l.c...@gm...> - 2011-04-07 17:07:41
|
Hello all, I wanted to make one configuration specification file for multiple versions of the configspec. That way as the requirements of the configspec change, only one configspec has to be updated and it will still work with the old and new specs. Right now I have the configspec in the following format: > specVersion = float(min=0.0) > > # Common among all versions > [common] > id = integer(min=0) > ... > > # Specific to Spec Version .2 > [.2] > width = integer() > > #specific to spec version .1 > [.1] > height = integer() > The issue I have is that I don't think I can write a custom validate function to only validate the needed sections. Is it not possible for me to do this? Will I just have to make different configspec files and load them based on what specVersion is? Does this even make sense?! Thank you for your help, Leonardo |
|
From: Michael F. <fuz...@vo...> - 2011-05-02 22:08:50
|
On 07/04/2011 18:07, L. Canessa wrote: > Hello all, > > I wanted to make one configuration specification file for multiple > versions of the configspec. That way as the requirements of the > configspec change, only one configspec has to be updated and it will > still work with the old and new specs. > > Right now I have the configspec in the following format: > > specVersion = float(min=0.0) > > # Common among all versions > [common] > id = integer(min=0) > ... > > # Specific to Spec Version .2 > [.2] > width = integer() > > #specific to spec version .1 > [.1] > height = integer() > > > The issue I have is that I don't think I can write a custom validate > function to only validate the needed sections. > Is it not possible for me to do this? Will I just have to make > different configspec files and load them based on what specVersion is? > Hello Leonardo, Sorry for the late reply. My daughter has just been born so life has been kind of hectic recently. ConfigObj has no support for multiple configspec versions, so I think you'll need several different configspec files and select them depending on which version you need (as you suggest). All the best, Michael Foord > Does this even make sense?! > > Thank you for your help, > Leonardo > > > ------------------------------------------------------------------------------ > Xperia(TM) PLAY > It's a major breakthrough. An authentic gaming > smartphone on the nation's most reliable network. > And it wants your games. > http://p.sf.net/sfu/verizon-sfdev > > > _______________________________________________ > Configobj-develop mailing list > Con...@li... > https://lists.sourceforge.net/lists/listinfo/configobj-develop -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html |
|
From: L. C. <l.c...@gm...> - 2011-05-02 22:02:28
|
Michael, It's quite all right on the late reply. I actually much prefer to find a solution myself, but I just wanted to check to see what other people with more experience with the library had done. What I ended up doing is to only validate based on the common + version section, and ignore the rest. The first key in the [common] section is "version", this allows me to easily pull the version number out. So when I pass the configuration object to the validator to be validated, I preserve errors, and subsequently only pay attention to errors that are in the [common] or [.1] section (if version is .1). Thus, I always fail validation, but I only check to see if the common + version in question failed or passed. It's not as clean as I would like; but it works. Do you / anyone else see multiple configspec versions as a worthwhile addition to the library? Thanks, Leonardo On Mon, May 2, 2011 at 5:40 PM, Michael Foord <fuz...@vo...>wrote: > On 07/04/2011 18:07, L. Canessa wrote: > > Hello all, > > I wanted to make one configuration specification file for multiple versions > of the configspec. That way as the requirements of the configspec change, > only one configspec has to be updated and it will still work with the old > and new specs. > > Right now I have the configspec in the following format: > >> specVersion = float(min=0.0) >> >> # Common among all versions >> [common] >> id = integer(min=0) >> ... >> >> # Specific to Spec Version .2 >> [.2] >> width = integer() >> >> #specific to spec version .1 >> [.1] >> height = integer() >> > > The issue I have is that I don't think I can write a custom validate > function to only validate the needed sections. > Is it not possible for me to do this? Will I just have to make different > configspec files and load them based on what specVersion is? > > > Hello Leonardo, > > Sorry for the late reply. My daughter has just been born so life has been > kind of hectic recently. > > ConfigObj has no support for multiple configspec versions, so I think > you'll need several different configspec files and select them depending on > which version you need (as you suggest). > > All the best, > > Michael Foord > > Does this even make sense?! > > Thank you for your help, > Leonardo > > > ------------------------------------------------------------------------------ > Xperia(TM) PLAY > It's a major breakthrough. An authentic gaming > smartphone on the nation's most reliable network. > And it wants your games.http://p.sf.net/sfu/verizon-sfdev > > > _______________________________________________ > Configobj-develop mailing lis...@li...://lists.sourceforge.net/lists/listinfo/configobj-develop > > > > -- http://www.voidspace.org.uk/ > > May you do good and not evil > May you find forgiveness for yourself and forgive others > May you share freely, never taking more than you give. > -- the sqlite blessing http://www.sqlite.org/different.html > > |
|
From: Michael F. <fuz...@vo...> - 2011-05-02 22:28:46
|
On 02/05/2011 23:02, L. Canessa wrote: > Michael, > > It's quite all right on the late reply. I actually much prefer to find > a solution myself, but I just wanted to check to see what other people > with more experience with the library had done. > > What I ended up doing is to only validate based on the common + > version section, and ignore the rest. The first key in the [common] > section is "version", this allows me to easily pull the version number > out. So when I pass the configuration object to the validator to be > validated, I preserve errors, and subsequently only pay attention to > errors that are in the [common] or [.1] section (if version is .1). > Thus, I always fail validation, but I only check to see if the common > + version in question failed or passed. > > It's not as clean as I would like; but it works. > > Do you / anyone else see multiple configspec versions as a worthwhile > addition to the library? > I think it would add complexity for a reasonably rare use case (and I suspect that different use cases would want different ways of specifying the version to use, so there isn't necessarily a "one size fits all" solution). It probably wouldn't be *very* hard to add it as a separate function or set of functions built on top of the validate library. You can look at the ConfigObj.validate method to see how the standard validation is implemented. All the best, Michael Foord > Thanks, > Leonardo > > > On Mon, May 2, 2011 at 5:40 PM, Michael Foord > <fuz...@vo... <mailto:fuz...@vo...>> wrote: > > On 07/04/2011 18:07, L. Canessa wrote: >> Hello all, >> >> I wanted to make one configuration specification file for >> multiple versions of the configspec. That way as the requirements >> of the configspec change, only one configspec has to be updated >> and it will still work with the old and new specs. >> >> Right now I have the configspec in the following format: >> >> specVersion = float(min=0.0) >> >> # Common among all versions >> [common] >> id = integer(min=0) >> ... >> >> # Specific to Spec Version .2 >> [.2] >> width = integer() >> >> #specific to spec version .1 >> [.1] >> height = integer() >> >> >> The issue I have is that I don't think I can write a custom >> validate function to only validate the needed sections. >> Is it not possible for me to do this? Will I just have to make >> different configspec files and load them based on what >> specVersion is? >> > > Hello Leonardo, > > Sorry for the late reply. My daughter has just been born so life > has been kind of hectic recently. > > ConfigObj has no support for multiple configspec versions, so I > think you'll need several different configspec files and select > them depending on which version you need (as you suggest). > > All the best, > > Michael Foord > >> Does this even make sense?! >> >> Thank you for your help, >> Leonardo >> >> >> ------------------------------------------------------------------------------ >> Xperia(TM) PLAY >> It's a major breakthrough. An authentic gaming >> smartphone on the nation's most reliable network. >> And it wants your games. >> http://p.sf.net/sfu/verizon-sfdev >> >> >> _______________________________________________ >> Configobj-develop mailing list >> Con...@li... <mailto:Con...@li...> >> https://lists.sourceforge.net/lists/listinfo/configobj-develop > > > -- > http://www.voidspace.org.uk/ > > May you do good and not evil > May you find forgiveness for yourself and forgive others > May you share freely, never taking more than you give. > -- the sqlite blessinghttp://www.sqlite.org/different.html > > > > ------------------------------------------------------------------------------ > WhatsUp Gold - Download Free Network Management Software > The most intuitive, comprehensive, and cost-effective network > management toolset available today. Delivers lowest initial > acquisition cost and overall TCO of any competing solution. > http://p.sf.net/sfu/whatsupgold-sd > > > _______________________________________________ > Configobj-develop mailing list > Con...@li... > https://lists.sourceforge.net/lists/listinfo/configobj-develop -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html |