Re: [Repoze-dev] bfg vs buildout

[Wichert Akkerman]

On 6/24/09 3:22 PM, Chris Withers wrote:
> Chris Rossi wrote:
>> On Wed, Jun 24, 2009 at 9:16 AM, Chris Withers> >  wrote:
>>
>>
>>  Also, how do you wire running tests, particularly running them with
>>  nose, into this?
>>
>> bin/nosetests path/to/src
>
> ...having added nosetests as a dependent egg, right?
>
> How/where do you encapsulate options to nosetests such that they don't
> have to be continuously re-typed?

setup.cfg

Wichert.



-- 
Wichert AkkermanIt is simple to make things.
http://www.wiggy.net/  It is hard to make things simple.
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] bfg vs buildout

[Chris McDonough]

On 6/25/09 9:08 AM, Jens W. Klein wrote:
> Am Thu, 25 Jun 2009 03:54:23 -0400 schrieb Chris McDonough:
>
>> On 6/25/09 3:38 AM, Chris Withers wrote:
>>> Shane Hathaway wrote:
 I'm not very familiar with pip, but I don't think that's an issue for
 Buildout.  Buildout also has the ability to pin the version of all
 packages, but I don't think that's what Jens and I want in this case.
>>> yep, the only thing buildout is missing is a command to dump the
>>> versions.cfg based on what's in the current buildout...
>>>
 We want an authority to provide a regularly updated list of Repoze
 package versions known to probably work together.  Thankfully, the BFG
 index is serving that purpose, except that it's not easy to combine
 that list with the rest of PyPI.  I think the problem would be solved
 if that index took the form of a versions.cfg (auto-generated would be
 fine).
>>> Yep, I wonder if Chris could be tickled to put your auto-generator up
>>> somewhere on dist.repoze.org?
>> I think it's a good idea.
>>
>> It's also an eminently doable-by-someone-else job (wget + the script).
>> I don't really use version.cfg files, so I'd be an unlikely candidate to
>> keep it running properly.  I'd forget about its existence and it would
>> just stop working.
>>
>> OTOH, if someone else wanted to keep an index mirror up and generate a
>> versions.cfg, and wget-against-the-index wasn't sufficient for some
>> reason, I'd do the necessary sysadmin stuff to get them rsync access to
>> the files (or really whatever was necessary).
>
> What about just publishing everything additional at pypi? I can provide a
> version.txt file at my servers for each release using Shanes script. This
> would be enough. Also then every pypi mirror could be used, no additional
> infrastructure needed.

Sorry, I think I miunsderstood how Shane's script works.  It generates a 
versions.cfg for every package in an index using HTTP.  It doesn't require 
access to the actual files themselves; I thought it did.

We already publish almost everything except the actual "repoze.bfg" package 
into 
PyPI.  I've been considering publishing that package to PyPI once we get to BFG 
1.0.  At which point, generating a versions.cfg from the "local" index and 
applying it to a buildout which used PyPI as an index would be reasonable.

You can also get what you wanted today if you generated a buildout in the form:

index = http://pypi.python.org/simple
find-links =
http://dist.repoze.org/bfg/1.0/repoze.bfg-1.0a3.tar.gz
http://dist.repoze.org/bfg/1.0/repoze.lru-0.3.tar.gz
.. and so on for each package needed by BFG ...

All *that* said, it's so blindingly easy to create an index for any given 
project, that just making one with what you need in it for that project 
(including the BFG stuff) seems like the best solution to me.

- C
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] bfg vs buildout

[Jens W. Klein]

Am Thu, 25 Jun 2009 03:54:23 -0400 schrieb Chris McDonough:

> On 6/25/09 3:38 AM, Chris Withers wrote:
>> Shane Hathaway wrote:
>>> I'm not very familiar with pip, but I don't think that's an issue for
>>> Buildout.  Buildout also has the ability to pin the version of all
>>> packages, but I don't think that's what Jens and I want in this case.
>>
>> yep, the only thing buildout is missing is a command to dump the
>> versions.cfg based on what's in the current buildout...
>>
>>> We want an authority to provide a regularly updated list of Repoze
>>> package versions known to probably work together.  Thankfully, the BFG
>>> index is serving that purpose, except that it's not easy to combine
>>> that list with the rest of PyPI.  I think the problem would be solved
>>> if that index took the form of a versions.cfg (auto-generated would be
>>> fine).
>>
>> Yep, I wonder if Chris could be tickled to put your auto-generator up
>> somewhere on dist.repoze.org?
> 
> I think it's a good idea.
> 
> It's also an eminently doable-by-someone-else job (wget + the script). 
> I don't really use version.cfg files, so I'd be an unlikely candidate to
> keep it running properly.  I'd forget about its existence and it would
> just stop working.
> 
> OTOH, if someone else wanted to keep an index mirror up and generate a
> versions.cfg, and wget-against-the-index wasn't sufficient for some
> reason, I'd do the necessary sysadmin stuff to get them rsync access to
> the files (or really whatever was necessary).

What about just publishing everything additional at pypi? I can provide a 
version.txt file at my servers for each release using Shanes script. This 
would be enough. Also then every pypi mirror could be used, no additional 
infrastructure needed.

best regards
-- 
Jens W. Klein - Klein & Partner KEG - BlueDynamics Alliance

___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] bfg vs buildout

[Chris McDonough]

On 6/25/09 3:38 AM, Chris Withers wrote:
> Shane Hathaway wrote:
>> I'm not very familiar with pip, but I don't think that's an issue for
>> Buildout.  Buildout also has the ability to pin the version of all
>> packages, but I don't think that's what Jens and I want in this case.
>
> yep, the only thing buildout is missing is a command to dump the
> versions.cfg based on what's in the current buildout...
>
>> We want an authority to provide a regularly updated list of Repoze
>> package versions known to probably work together.  Thankfully, the BFG
>> index is serving that purpose, except that it's not easy to combine that
>> list with the rest of PyPI.  I think the problem would be solved if that
>> index took the form of a versions.cfg (auto-generated would be fine).
>
> Yep, I wonder if Chris could be tickled to put your auto-generator up
> somewhere on dist.repoze.org?

I think it's a good idea.

It's also an eminently doable-by-someone-else job (wget + the script).  I don't 
really use version.cfg files, so I'd be an unlikely candidate to keep it 
running 
properly.  I'd forget about its existence and it would just stop working.

OTOH, if someone else wanted to keep an index mirror up and generate a 
versions.cfg, and wget-against-the-index wasn't sufficient for some reason, I'd 
do the necessary sysadmin stuff to get them rsync access to the files (or 
really 
whatever was necessary).

- C
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] bfg vs buildout

[Chris Withers]

Shane Hathaway wrote:
> I'm not very familiar with pip, but I don't think that's an issue for 
> Buildout.  Buildout also has the ability to pin the version of all 
> packages, but I don't think that's what Jens and I want in this case.

yep, the only thing buildout is missing is a command to dump the 
versions.cfg based on what's in the current buildout...

> We want an authority to provide a regularly updated list of Repoze 
> package versions known to probably work together.  Thankfully, the BFG 
> index is serving that purpose, except that it's not easy to combine that 
> list with the rest of PyPI.  I think the problem would be solved if that 
> index took the form of a versions.cfg (auto-generated would be fine).

Yep, I wonder if Chris could be tickled to put your auto-generator up 
somewhere on dist.repoze.org?

Chris

-- 
Simplistix - Content Management, Zope & Python Consulting
- http://www.simplistix.co.uk
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] bfg vs buildout

[zope]

Hi Shane,
> z...@kevinkal.com wrote:
>>   I've become a big fan of pip.  The --freeze option is great.  It 
>> seems that it lets you pin your versions all the way down.  I'm just 
>> watching all of the pain with certain buildout recipes where I could 
>> imagine them easier to create if the person creating the recipe had 
>> the possibility to pin every version easily.
>
> I'm not very familiar with pip,
pip, I don't think is a competator for buildout, but an alternative for 
easyinstall
> but I don't think that's an issue for Buildout.  Buildout also has the 
> ability to pin the version of all packages, but I don't think that's 
> what Jens and I want in this case.
>
> We want an authority to provide a regularly updated list of Repoze 
> package versions known to probably work together.  Thankfully, the BFG 
> index is serving that purpose, 
Ok,  I may have missed the main point of this thread, but ... :-)
> except that it's not easy to combine that list with the rest of PyPI.  
I thought it was more about this - which pip can help with.   "bin/pip 
--freeze" produces a list of all eggs in pip's path.  One could do a 
"pip --freeze > versions.cfg"

There is a buildout recipe that uses pip - 
http://pypi.python.org/pypi/gp.recipe.pip .d

> I think the problem would be solved if that index took the form of a 
> versions.cfg (auto-generated would be fine).
>
> Shane
>

Again - I'm not sure how far off the point I am with this thread,  but 
when I see buildout mentioned I think of the serious troubles I have had 
with certain popular recipes and wish that the help with pinning that 
pip brings to the table would be taken advantage of. 

Cheers!
-Kevin

___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] bfg vs buildout

[Shane Hathaway]

z...@kevinkal.com wrote:
>   I've become a big fan of pip.  The --freeze option is great.  It seems 
> that it lets you pin your versions all the way down.  I'm just watching 
> all of the pain with certain buildout recipes where I could imagine them 
> easier to create if the person creating the recipe had the possibility 
> to pin every version easily.

I'm not very familiar with pip, but I don't think that's an issue for 
Buildout.  Buildout also has the ability to pin the version of all 
packages, but I don't think that's what Jens and I want in this case.

We want an authority to provide a regularly updated list of Repoze 
package versions known to probably work together.  Thankfully, the BFG 
index is serving that purpose, except that it's not easy to combine that 
list with the rest of PyPI.  I think the problem would be solved if that 
index took the form of a versions.cfg (auto-generated would be fine).

Shane

___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] bfg vs buildout

[zope]

Hi All,
  I've become a big fan of pip.  The --freeze option is great.  It seems 
that it lets you pin your versions all the way down.  I'm just watching 
all of the pain with certain buildout recipes where I could imagine them 
easier to create if the person creating the recipe had the possibility 
to pin every version easily.

-Kevin


Shane Hathaway wrote:
> Jens W. Klein wrote:
>> Am Wed, 24 Jun 2009 09:59:14 -0400 schrieb Tres Seaver:
>> [..]
 Missing is a version fixation like done in ZTK, Grok, Plone, ... I'd
 really like to see such a version.cfg for each repoze release. 
 Creation
 could be automated.
>>> You shouldn't need to pin the versions if you would use the index as an
>>> index:
>>>
>>>index = http://dist.repoze.org/bfg/1.0/simple
>>>
>>> That index is a "known good set" for the 1.0 release line of BFG.
>>
>> If one uses only stuff from the given index it works. Now, using 
>> stuff from pypi like repoze.what make live difficult using an own 
>> index server.
>
> I agree it's useful to have a versions.cfg, so I wrote a WSGI script 
> that generates a versions.cfg from a package index.  I have attached 
> it.  It probably needs some battle testing and TLC.
>
> Shane
>
> 
>
> ___
> Repoze-dev mailing list
> Repoze-dev@lists.repoze.org
> http://lists.repoze.org/listinfo/repoze-dev

___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] bfg vs buildout

[Shane Hathaway]

Jens W. Klein wrote:

Am Wed, 24 Jun 2009 09:59:14 -0400 schrieb Tres Seaver:
[..]

Missing is a version fixation like done in ZTK, Grok, Plone, ... I'd
really like to see such a version.cfg for each repoze release. Creation
could be automated.

You shouldn't need to pin the versions if you would use the index as an
index:

   index = http://dist.repoze.org/bfg/1.0/simple

That index is a "known good set" for the 1.0 release line of BFG.


If one uses only stuff from the given index it works. Now, using stuff 
from pypi like repoze.what make live difficult using an own index server.


I agree it's useful to have a versions.cfg, so I wrote a WSGI script 
that generates a versions.cfg from a package index.  I have attached it. 
 It probably needs some battle testing and TLC.


Shane


URI = 'http://dist.repoze.org/bfg/1.0/'

import lxml.html
import os
import pkg_resources
import urlparse

def application(environ, start_response):
packages = get_index_versions(URI)
lines = ['[versions]']
for pkg_name, version in sorted(packages.items()):
lines.append('%s = %s' % (pkg_name, version))
text = '\n'.join(lines)
start_response([
('Content-Type', 'text/plain'),
('Content-Length', str(len(text))),
])
return [text]

def get_index_versions(uri):
packages = {}  # pkg_name -> [(parsed version, version)]
doc = lxml.html.parse(uri)
for e in doc.findall('//a'):
href = e.get('href')
if not href:
continue
path = urlparse.urlsplit(href)[2]
parts = filter(None, path.split('/'))
if not parts:
continue
basename, ext = os.path.splitext(parts[-1])
ext = ext.lower()
if ext == '.egg':
# remove the '-pyX.Y-Z' suffixes
basename = '-'.join(basename.split('-')[:-2])
elif ext in ('.gz', '.bz2'):
basename, ext = os.path.splitext(basename)
ext = ext.lower()
if ext not in ('.tar', '.zip', '.egg', '.tgz', '.tbz2'):
continue
pkg_name, version = basename.split('-', 1)
parsed_version = pkg_resources.parse_version(version)
versions = packages.setdefault(pkg_name, [])
versions.append((parsed_version, version))
res = {}
for pkg_name, versions in packages.items():
versions.sort()
res[pkg_name] = versions[-1][1]
return res

if __name__ == '__main__':
print ''.join(application({}, lambda headers: None))
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] bfg vs buildout

[Jens W. Klein]

Am Wed, 24 Jun 2009 09:59:14 -0400 schrieb Tres Seaver:
[..]
>> Missing is a version fixation like done in ZTK, Grok, Plone, ... I'd
>> really like to see such a version.cfg for each repoze release. Creation
>> could be automated.
> 
> You shouldn't need to pin the versions if you would use the index as an
> index:
> 
>index = http://dist.repoze.org/bfg/1.0/simple
> 
> That index is a "known good set" for the 1.0 release line of BFG.

If one uses only stuff from the given index it works. Now, using stuff 
from pypi like repoze.what make live difficult using an own index server.

So, this does _not_ work (repoze.what is on pypi):
--
[buildout]
# broken
parts = instance
index = http://dist.repoze.org/bfg/1.0/simple

[instance]
recipe = repoze.recipe.egg:scripts
eggs = repoze.bfg repoze.what
---

This one is broken too, repoze.what has an dependency on repoze.bfg!
---
[buildout]
# broken
parts = instance
eggs = repoze.what

[instance]
recipe = repoze.recipe.egg:scripts
index = http://dist.repoze.org/bfg/1.0/simple
eggs = repoze.bfg ${buildout:eggs}



But this works, even if it warns: 
"Couldn't find index page for repoze.what" (whie processing instance)

[buildout]
# works
parts = instance

[pypi]
recipe = repoze.recipe.egg
eggs = repoze.what

[instance]
recipe = repoze.recipe.egg:scripts
index = http://dist.repoze.org/bfg/1.0/simple
eggs =
${pypi:eggs}
repoze.bfg


After all, having it all in an own index makes things much more difficult 
than putting it all at pypi and having a version.cfg available.

I'd really love to see an approach like:


[buildout]
# future?
parts = instance
extends = http://dist.repoze.org/bfg/1.0/versions.cfg
find-links = http://dist.repoze.org/bfg/1.0
versions = versions

[instance]
recipe = repoze.recipe.egg:scripts
eggs = repoze.bfg repoze.what

Latter method is widely used good practice. Since we already have "find-
links" this way available the only missing piece is the versions.cfg 
which need to be created for each release.

best regards
-- 
Jens W. Klein - Klein & Partner KEG - BlueDynamics Alliance

___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] bfg vs buildout

[Chris Withers]

Tres Seaver wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Chris Withers wrote:
>> Chris Rossi wrote:
>>> On Wed, Jun 24, 2009 at 9:16 AM, Chris Withers >> > wrote:
>>>
>>>
>>> Also, how do you wire running tests, particularly running them with
>>> nose, into this?
>>>
>>> bin/nosetests path/to/src
>> ...having added nosetests as a dependent egg, right?
>>
>> How/where do you encapsulate options to nosetests such that they don't 
>> have to be continuously re-typed?
> 
> You can put them in the [nosetests] section of setup.cfg, and then run
> the tests via '/path/to/python setup.py nosetests' (having first
> installed 'Nose', and maybe 'coverage').

The question was in the context of buildout, so I guess this would 
translate to:

- add nose and coverage to required eggs

- bin/buildout setup path/to/my/package/setup.py nosetests

?

That feels a bit cumbersome, is there any way to use zc.recipe.egg or 
some other recipe such that I can just do:

bin/test

?

Also, has anyone found a way to get buildout to do something with eggs 
specified in test_requires? (ie: bake them into a script rather than 
letting setuptools just install them randomly into your source tree)

cheers,

Chris

-- 
Simplistix - Content Management, Zope & Python Consulting
- http://www.simplistix.co.uk
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] bfg vs buildout

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Chris Withers wrote:
> Chris Rossi wrote:
>> On Wed, Jun 24, 2009 at 9:16 AM, Chris Withers > > wrote:
>>
>>
>> Also, how do you wire running tests, particularly running them with
>> nose, into this?
>>
>> bin/nosetests path/to/src
> 
> ...having added nosetests as a dependent egg, right?
> 
> How/where do you encapsulate options to nosetests such that they don't 
> have to be continuously re-typed?

You can put them in the [nosetests] section of setup.cfg, and then run
the tests via '/path/to/python setup.py nosetests' (having first
installed 'Nose', and maybe 'coverage').


Tres.
- --
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFKQjN8+gerLs4ltQ4RAhSmAKC5mqHmOpPbHc4lk/GardoZL3dfIACgnr9w
KhzWrrwWrLS9vULR6KyV2CY=
=N6jH
-END PGP SIGNATURE-
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] bfg vs buildout

[Chris Withers]

Chris Rossi wrote:
> 
> 
> (karl3)ch...@opportunity:~/proj/karl3/src/karl$ cat test
> ../../bin/nosetests $*
> 
> So, we just do:
> 
> $ cd src/karl
> $ ./test

Hackish, but I guess functional. Sadly not cross platform.

I wonder if a little buildout recipe is in order?

I see:

http://pypi.python.org/pypi/pbp.recipe.noserunner

...but this doesn't seem to be much more than a wrapper around 
zc.recipe.egg and doesn't offer any way to store nose config options in 
buildout.cfg.

cheers,

Chris

-- 
Simplistix - Content Management, Zope & Python Consulting
- http://www.simplistix.co.uk
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] bfg vs buildout

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jens W. Klein wrote:
> Am Wed, 24 Jun 2009 10:54:33 +0100 schrieb Chris Withers:
> 
>> Hey All,
>>
>> Just been reading http://docs.repoze.org/bfg/narr/install.html and I
>> notice a conspicuous absence of zc.buildout...
>>
>> Do you guys recommend not using buildout? If not, are there docs
>> anywhere for using BFG in a buildout context?
> 
> I do use zc.buildout. Here an minimal example:
> 
> -
> [buildout]
> extensions = buildout.dumppickedversions
> parts = instance
> eggs-directory = ${buildout:directory}/eggs
> find-links = 
> http://dist.repoze.org/bfg/1.0/
> 
> [instance]
> recipe = repoze.recipe.egg:scripts
> eggs =
> repoze.bfg
> 
> Missing is a version fixation like done in ZTK, Grok, Plone, ... 
> I'd really like to see such a version.cfg for each repoze release. 
> Creation could be automated.

You shouldn't need to pin the versions if you would use the index as an
index:

   index = http://dist.repoze.org/bfg/1.0/simple

That index is a "known good set" for the 1.0 release line of BFG.



Tres.
- --
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFKQjEy+gerLs4ltQ4RAoIlAJoCoQ6jPYE7jW06AmEJdLCe+XjkeACfTNUZ
tEG4Ry4RTK9DJou+AYEGTJ0=
=k5wN
-END PGP SIGNATURE-
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] bfg vs buildout

[Jens W. Klein]

Am Mittwoch, den 24.06.2009, 08:52 -0400 schrieb Chris Rossi:
[...]
> Not really missing, just done in a different way.  The index itself is 
> populated only with a KGS and maintained to be up to date.  The 
> Agendaless guys also typically make a private index for each customer
> project that they work on--so they still keep the versions pinned, they
> just don't rely on buildout to do that, opting for custom indexes
> instead.

Well, this approach might be one way to go, but without offering a 
version.cfg with all versions used in the release its the only way to go. 
I prefer to have the choice.

> As far as using buildout, since bfg is distributed as a bunch of eggs,
> all you really have to do is instruct your buildout to pull from an
> index with the bfg eggs available and then install bfg, so there's not
> much to it, really.  If your project only depends on other stuff that 
> can be easy_installed there may not be much advantage to using
> buildout, but it's certainly very easy to do and might help to manage
> more complicated deployments.
 
As said, having two index= in one buildout - the only way to make it work 
with eggs from pypi and version pinned repoze.bfg - is a complicated 
construct. It works but for sure buildout was not made to support it.

A simple solution to give people a choice is: 

a) provide a version.cfg for each release
b) (optional) release everything on pypi as well 

-- 
Jens W. Klein - Klein & Partner KEG - BlueDynamics Alliance

___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] bfg vs buildout

[Jens W. Klein]

Am Wed, 24 Jun 2009 14:16:38 +0100 schrieb Chris Withers:

> Jens W. Klein wrote:
[...]
>> Missing is a version fixation like done in ZTK, Grok, Plone, ... I'd
>> really like to see such a version.cfg for each repoze release. Creation
>> could be automated.
> 
> Why don't you just replace find-links with index?

Because it sucks if you have to use other packages not in this special 
'private' index. I found a way to mix two "index =" in one buildout, but 
its really a PITA. I'd really prefer to have a version.cfg. As said its 
not difficult to create such a thing from the data found in the private 
index (version info in there).

> Also, how do you wire running tests, particularly running them with
> nose, into this?

i didnt try to use nose for my tests, i stuck to zc.recipe.testrunner for 
the moment. yes, i'd like to learn how to use nose in this context, but 
didnt found time.

regards
-- 
Jens W. Klein - Klein & Partner KEG - BlueDynamics Alliance

___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] bfg vs buildout

[Chris Rossi]

On Wed, Jun 24, 2009 at 9:22 AM, Chris Withers wrote:

>
>
> How/where do you encapsulate options to nosetests such that they don't have
> to be continuously re-typed?
>
>  The project I work on where we do this, we just write a shell script and
check it in to svn.  If you were to look in the Karl buildout you'd find the
src dirs have scripts called 'test' that just look like:

(karl3)ch...@opportunity:~/proj/karl3/src/karl$ cat test
../../bin/nosetests $*

So, we just do:

$ cd src/karl
$ ./test

Chris
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] bfg vs buildout

[Chris Withers]

Chris Rossi wrote:
> On Wed, Jun 24, 2009 at 9:16 AM, Chris Withers  > wrote:
> 
> 
> Also, how do you wire running tests, particularly running them with
> nose, into this?
> 
> bin/nosetests path/to/src

...having added nosetests as a dependent egg, right?

How/where do you encapsulate options to nosetests such that they don't 
have to be continuously re-typed?

Chris

-- 
Simplistix - Content Management, Zope & Python Consulting
- http://www.simplistix.co.uk
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] bfg vs buildout

[Chris Rossi]

On Wed, Jun 24, 2009 at 9:16 AM, Chris Withers wrote:

>
> Also, how do you wire running tests, particularly running them with
> nose, into this?
>
> bin/nosetests path/to/src

Chris
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] bfg vs buildout

[Chris Withers]

Jens W. Klein wrote:
> -
> [buildout]
> extensions = buildout.dumppickedversions
> parts = instance
> eggs-directory = ${buildout:directory}/eggs
> find-links = 
> http://dist.repoze.org/bfg/1.0/
> 
> [instance]
> recipe = repoze.recipe.egg:scripts
> eggs =
> repoze.bfg
> 
> Missing is a version fixation like done in ZTK, Grok, Plone, ... 
> I'd really like to see such a version.cfg for each repoze release. 
> Creation could be automated.

Why don't you just replace find-links with index?

Also, how do you wire running tests, particularly running them with 
nose, into this?

cheers,

Chris

-- 
Simplistix - Content Management, Zope & Python Consulting
- http://www.simplistix.co.uk
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] bfg vs buildout

[Jens W. Klein]

Am Wed, 24 Jun 2009 10:54:33 +0100 schrieb Chris Withers:

> Hey All,
> 
> Just been reading http://docs.repoze.org/bfg/narr/install.html and I
> notice a conspicuous absence of zc.buildout...
> 
> Do you guys recommend not using buildout? If not, are there docs
> anywhere for using BFG in a buildout context?

I do use zc.buildout. Here an minimal example:

-
[buildout]
extensions = buildout.dumppickedversions
parts = instance
eggs-directory = ${buildout:directory}/eggs
find-links = 
http://dist.repoze.org/bfg/1.0/

[instance]
recipe = repoze.recipe.egg:scripts
eggs =
repoze.bfg

Missing is a version fixation like done in ZTK, Grok, Plone, ... 
I'd really like to see such a version.cfg for each repoze release. 
Creation could be automated.

hth & greetz
-- 
Jens W. Klein - Klein & Partner KEG - BlueDynamics Alliance

___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev