what are your next release plans

[Toby Dacre]

Hi,

I'm working on the ckan project ckan.org and we are looking at using
fanstatic to serve our .css .js resources. Currently there are a
couple of issues that make this difficult. I added them (and patches)
to your bit bucket issue tracker. For us to use fanstatic we'd really
like to have a version available on pypi that resolves these issues.

I see that in november you were looking for co-maintainers. If this
is still the case I'd be happy to spend some time going through issue
tracker etc.

Thanks
Toby

[Jan-Jaap Driessen]

Hi Toby,

On Tue, May 8, 2012 at 1:12 PM, Toby Dacre <toby...@gmail.com> wrote:
> Hi,
>
> I'm working on the ckan project ckan.org and we are looking at using
> fanstatic to serve our .css .js resources.  Currently there are a
> couple of issues that make this difficult.  I added them (and patches)
> to your bit bucket issue tracker.  For us to use fanstatic we'd really
> like to have a version available on pypi that resolves these issues.

I saw your pull requests and will have a look at them. I hope to push
a fanstatic release to pypi tonight (GMT+1).

> I see that in november you were looking for co-maintainers.  If this
> is still the case I'd be happy to spend some time going through issue
> tracker etc.

We welcome contributions. Martijn and I had some discussions on
fanstatic features last week, now it's just a matter of implementing
them. I'll write up a post to the mailing list soon.

> Thanks
> Toby

Cheers,

JJ

[Toby Dacre]

On 8 May 2012 13:14, Jan-Jaap Driessen <janjaap...@gmail.com> wrote:

Hi Toby,

On Tue, May 8, 2012 at 1:12 PM, Toby Dacre <toby...@gmail.com> wrote:
> Hi,
>
> I'm working on the ckan project ckan.org and we are looking at using
> fanstatic to serve our .css .js resources.  Currently there are a
> couple of issues that make this difficult.  I added them (and patches)
> to your bit bucket issue tracker.  For us to use fanstatic we'd really
> like to have a version available on pypi that resolves these issues.

I saw your pull requests and will have a look at them. I hope to push
a fanstatic release to pypi tonight (GMT+1).

Thanks that would be great

> I see that in november you were looking for co-maintainers.  If this
> is still the case I'd be happy to spend some time going through issue
> tracker etc.

We welcome contributions. Martijn and I had some discussions on
fanstatic features last week, now it's just a matter of implementing
them. I'll write up a post to the mailing list soon.

Let me know if you need a hand

I have one more request :)
I'd like to be able to dynamically load libraries without having to register entry_points for them as that requires re running setup.py etc.  What would be great is to have an extra entry point for loading dynamic entry points

so
setup.py
[fanstatic.dynamic]
dynamic_entry_points = foo:bar

foo:bar would be able to return a list of entry points ['foo = moo:foo', 'bar = moo:bar']

I've done a small proof of concept and it looks like it should be fairly easy to get working.  Let me know if this would be acceptable and I'll knock a patch up.

Thanks again for your work

Toby




 

> Thanks
> Toby

Cheers,

JJ

[Martijn Faassen]

Hey Jan-Jaap and Toby,

I've handled Toby's issues (thanks Toby!) except for the script name
one, where I really would like Jan-Jaap to take a look and have a bit
of discussion. Here's the issue:

https://bitbucket.org/fanstatic/fanstatic/issue/76/support-serving-from-none-site-root

Comparing this patch where environ is passed along to the previous one
where script_name was passed directly, I actually prefer the previous
patch. The problem however is that it touches a lot of tests and
that's not very nice, I agree.

I'm trying to figure out what the proper interaction between base_url,
script name and WSGI middleware is. Does Fanstatic (or any WSGI app)
need to be aware of SCRIPT_NAME in its code or is this something that
something else can be responsible for? I don't know and I think some
discussion is needed to see what the right way forward should be.

Regards,

Martijn

[Martijn Faassen]

Hi there,

On Tue, May 8, 2012 at 3:13 PM, Toby Dacre <toby...@gmail.com> wrote:
> I'd like to be able to dynamically load libraries without having to register
> entry_points for them as that requires re running setup.py etc.

I'm curious about the underlying use cases, could you go into a bit more detail?

> What would
> be great is to have an extra entry point for loading dynamic entry points
>
> so
> setup.py
> [fanstatic.dynamic]
> dynamic_entry_points = foo:bar
>
> foo:bar would be able to return a list of entry points ['foo = moo:foo',
> 'bar = moo:bar']
>
> I've done a small proof of concept and it looks like it should be fairly
> easy to get working.  Let me know if this would be acceptable and I'll knock
> a patch up.

If we figure out the use cases, I'm not against such a patch. Please
do include tests for this stuff if you can, though. See
fixtures/MyPackage for a package to which you could add the dynamic
entry point stuff, we already use it for other tests.

Regards,

Martijn

[Jeff Dairiki]

On Tue, May 08, 2012 at 02:13:42PM +0100, Toby Dacre wrote:
> I'd like to be able to dynamically load libraries without having to
> register entry_points for them as that requires re running setup.py etc.
> What would be great is to have an extra entry point for loading dynamic
> entry points
>
> so
> setup.py
> [fanstatic.dynamic]
> dynamic_entry_points = foo:bar
>
> foo:bar would be able to return a list of entry points ['foo = moo:foo',
> 'bar = moo:bar']
>
> I've done a small proof of concept and it looks like it should be fairly
> easy to get working. Let me know if this would be acceptable and I'll
> knock a patch up.

I think this is a good idea.

I'd suggest, however, that rather than introducing a new indirect
entry point, just keep a list of entry points internally and provide
an API to add to the list. See the way dogpile.cache handles this
with register_backend().

http://dogpilecache.readthedocs.org/en/latest/usage.html#creating-backends

https://bitbucket.org/zzzeek/dogpile.cache/src/0232773bbda4/dogpile/cache/region.py#cl-10
https://bitbucket.org/zzzeek/dogpile.cache/src/0232773bbda4/dogpile/cache/util.py#cl-44

Jeff

[Toby Dacre]

On 8 May 2012 15:06, Jeff Dairiki <dai...@dairiki.org> wrote:

On Tue, May 08, 2012 at 02:13:42PM +0100, Toby Dacre wrote:
> I'd like to be able to dynamically load libraries without having to
> register entry_points for them as that requires re running setup.py etc.
> What would be great is to have an extra entry point for loading dynamic
> entry points
>
> so
> setup.py
> [fanstatic.dynamic]
> dynamic_entry_points = foo:bar
>
> foo:bar would be able to return a list of entry points ['foo = moo:foo',
> 'bar = moo:bar']
>
> I've done a small proof of concept and it looks like it should be fairly
> easy to get working.  Let me know if this would be acceptable and I'll
> knock a patch up.

I think this is a good idea.

I'd suggest, however, that rather than introducing a new indirect
entry point, just keep a list of entry points internally and provide
an API to add to the list.  See the way dogpile.cache handles this
with register_backend().

OK I can do this it is a nicer interface I'll have a go tomorrow

[Jan-Jaap Driessen]

On Tue, May 8, 2012 at 3:16 PM, Martijn Faassen <faa...@startifact.com> wrote:
> Hey Jan-Jaap and Toby,
>
> I've handled Toby's issues (thanks Toby!) except for the script name
> one, where I really would like Jan-Jaap to take a look and have a bit
> of discussion. Here's the issue:
>
> https://bitbucket.org/fanstatic/fanstatic/issue/76/support-serving-from-none-site-root
>
> Comparing this patch where environ is passed along to the previous one
> where script_name was passed directly, I actually prefer the previous
> patch. The problem however is that it touches a lot of tests and
> that's not very nice, I agree.

I created a branch of fanstatic where I cherry picked the changes in
Eric's pull request:

https://bitbucket.org/fanstatic/fanstatic/changeset/d76cbd002c8f

I changed `script_name` from a positional to a keyword argument, so
the tests are affected less.

> I'm trying to figure out what the proper interaction between base_url,
> script name and WSGI middleware is. Does Fanstatic (or any WSGI app)
> need to be aware of SCRIPT_NAME in its code or is this something that
> something else can be responsible for? I don't know and I think some
> discussion is needed to see what the right way forward should be.

I don't have an answer to your question; In my applications and
deployments, I have never had to work with SCRIPT_NAME.

Another question: Shouldn't both `base_url` and `script_name` be used
to influence the computation of the library_url?
It looks like that's what Eric wants:

https://bitbucket.org/fanstatic/fanstatic/pull-request/1/support-wsgi-apps-not-mounted-at#chg_fanstatic/test_core.py_newline536

One of the tests on my branch currently fails, because I don't know
what to do here.


Cheers,

JJ

[Jan-Jaap Driessen]

On Mon, May 14, 2012 at 1:35 PM, Toby Dacre <toby...@gmail.com> wrote:
> Jan-Jaap,
>
> Sorry didn't realise the question was aimed at me.

No problem.

I moved this conversation to the fanstatic mailing list so we can have
more eyes looking at this discussion and get to the next release of
fanstatic.

> On 13 May 2012 19:36, Jan-Jaap Driessen <janjaap...@gmail.com> wrote:
...

>> > I don't have an answer to your question; In my applications and
>> > deployments, I have never had to work with SCRIPT_NAME.
>
>

> SCRIPT_NAME is something I have to regularly use due to non-root deployment
> of applications.  Part of the problem is that the application doesn't know
> it's root until the first request arrives and so for example we cannot do
>
>      app = Fanstatic(app, base_url='...')
>
> Looking at the code it does seem that I can set the base_url via
> get_needed().set_base_url() which should work I need to test this.
> Alternatively if there was a way to set the config base_url externally then
> the application could worry about SCRIPT_NAME rather than Fanstatic.

This reminds me of some code in `zope.fanstatic` where we integrate
fanstatic in zope applications; at the end of the zope request cycle
the base_url is set on the NeededResources object (if it has not been
set already):

http://zope3.pov.lt/trac/browser/zope.fanstatic/trunk/src/zope/fanstatic/zopesupport.py#L46

I guess this would work in your situation. Which web framework do you use?

>> > Another question: Shouldn't both `base_url` and `script_name` be used
>> > to influence the computation of the library_url?
>> > It looks like that's what Eric wants:
>

> I think Eric like me wants a way of being able to dynamically get the site
> root rather than having to specify it in a .ini file,  The script_name is a
> fallback and base_url should be honoured if it is provided.

OK, that makes sense to me now. I have updated the fanstatic branch;
could you check whether this works in your project?

> base_url or script_name should be used but not both.  Eric's pull request
> behaves like this

>> > https://bitbucket.org/fanstatic/fanstatic/pull-request/1/support-wsgi-apps-not-mounted-at#chg_fanstatic/test_core.py_newline536
>> >
>> > One of the tests on my branch currently fails, because I don't know
>> > what to do here.
>

> On current master tip e91e7edee152   I'm getting test fails for the
> test_checksum tests not sure why.

I don't have failings tests right now. Could you pull the most recent
changes and test again? If the tests fail on your machine could you
send an overview of the failing tests?

> Let me know if you need more info or I've not answered some questions

Thanks,

JJ

[Toby Dacre]

we use pylons
 

>> > Another question: Shouldn't both `base_url` and `script_name` be used
>> > to influence the computation of the library_url?
>> > It looks like that's what Eric wants:
>
> I think Eric like me wants a way of being able to dynamically get the site
> root rather than having to specify it in a .ini file,  The script_name is a
> fallback and base_url should be honoured if it is provided.

OK, that makes sense to me now. I have updated the fanstatic branch;
could you check whether this works in your project?

Thanks I'll do that and get back to you
 

> base_url or script_name should be used but not both.  Eric's pull request
> behaves like this
>> > https://bitbucket.org/fanstatic/fanstatic/pull-request/1/support-wsgi-apps-not-mounted-at#chg_fanstatic/test_core.py_newline536
>> >
>> > One of the tests on my branch currently fails, because I don't know
>> > what to do here.
>
> On current master tip e91e7edee152   I'm getting test fails for the
> test_checksum tests not sure why.

I don't have failings tests right now. Could you pull the most recent
changes and test again? If the tests fail on your machine could you
send an overview of the failing tests?

again, I'll do this hopefully it's just something stupid on my part.  It'll have to wait till tomorrow though.


I don't suppose you've had a chance to look at issue 77 https://bitbucket.org/fanstatic/fanstatic/issue/77/allow-dynamic-loading-of-libraries
That would make me super happy :)

Thanks again

Toby

[Toby Dacre]

The patch works as expected, sorry I was sick yesterday

 

> base_url or script_name should be used but not both.  Eric's pull request
> behaves like this
>> > https://bitbucket.org/fanstatic/fanstatic/pull-request/1/support-wsgi-apps-not-mounted-at#chg_fanstatic/test_core.py_newline536
>> >
>> > One of the tests on my branch currently fails, because I don't know
>> > what to do here.
>
> On current master tip e91e7edee152   I'm getting test fails for the
> test_checksum tests not sure why.

I don't have failings tests right now. Could you pull the most recent
changes and test again? If the tests fail on your machine could you
send an overview of the failing tests?

again, I'll do this hopefully it's just something stupid on my part.  It'll have to wait till tomorrow though.

I still have a test issue but this may well just be my setup

 fanstatic/test_bundle.py ..
fanstatic/test_checksum.py FFFFFFF
fanstatic/test_codegen.py ...
fanstatic/test_config.py ....
fanstatic/test_core.py ...........................................................................
fanstatic/test_injector.py .......
fanstatic/test_publisher.py ...........
fanstatic/test_registry.py .
fanstatic/test_slot.py ..........
fanstatic/test_wsgi.py ......

 ================================================ FAILURES ================================================
__________________________________________ test_list_directory ___________________________________________

tmpdir = local('/tmp/pytest-8/test_list_directory0')

    def test_list_directory(tmpdir):
        testdata_path = str(_copy_testdata(tmpdir))
        expected = [
            tmpdir.join('MyPackage/setup.py').strpath,
            tmpdir.join('MyPackage/MANIFEST.in').strpath,
            tmpdir.join('MyPackage/src/mypackage/__init__.py').strpath,
            tmpdir.join('MyPackage/src/mypackage/resources/style.css').strpath,
            ]
        found = list(list_directory(testdata_path, include_directories=False))
>       assert sorted(found) == sorted(expected)
E       assert ['/tmp/pytest...KG-INFO', ...] == ['/tmp/pytest-...es/style.css']
E         At index 1 diff: '/tmp/pytest-8/test_list_directory0/MyPackage/build/lib/mypackage/__init__.py' != '/tmp/pytest-8/test_list_directory0/MyPackage/setup.py'
E         Left contains more items, first extra item: '/tmp/pytest-8/test_list_directory0/MyPackage/setup.py'

fanstatic/test_checksum.py:26: AssertionError

[Martijn Faassen]

Hey,

On Wed, May 16, 2012 at 8:00 PM, Toby Dacre <toby...@gmail.com> wrote:
>
> I still have a test issue but this may well just be my setup

That's interesting, looks like it's platform dependent, possibly some
difference in the way setuptools is setup. What python version are you
using? What platform? setuptools or distutils?

> fanstatic/test_checksum.py FFFFFFF

Could you create an issue for this one with that info in it, so we
don't forget it?

Regards,

Martijn

[Toby Dacre]

On 16 May 2012 19:43, Martijn Faassen <faa...@startifact.com> wrote:

Hey,

On Wed, May 16, 2012 at 8:00 PM, Toby Dacre <toby...@gmail.com> wrote:
>
> I still have a test issue but this may well just be my setup

That's interesting, looks like it's platform dependent, possibly some
difference in the way setuptools is setup. What python version are you
using? What platform? setuptools or distutils?

Python 2.7.3
Arch Linux  3.3.4-2-ARCH
distutils

I think this is just some interaction with some stuff in my pyenv.  I did a fresh install of fanstatic in a clean environment and these errors no longer occur.

Let me know if you still want an issue logging but it feels unnecessary

Cheers

Toby

[Jan-Jaap Driessen]

On Mon, May 14, 2012 at 10:18 PM, Toby Dacre <toby...@gmail.com> wrote:
...

> I don't suppose you've had a chance to look at issue 77
> https://bitbucket.org/fanstatic/fanstatic/issue/77/allow-dynamic-loading-of-libraries
> That would make me super happy :)

I added a comment to that issue; I think there's an easier way to load
libraries during runtime of the application.

You mentioned before that you would like to have an entry points that
points to a list of libraries; could you put the code for that in a
pull request, so we can have a look?

Cheers,

JJ

[Martijn Faassen]

Hallo,

On Thu, May 17, 2012 at 11:51 AM, Toby Dacre <toby...@gmail.com> wrote:
> On 16 May 2012 19:43, Martijn Faassen <faa...@startifact.com> wrote:
>> On Wed, May 16, 2012 at 8:00 PM, Toby Dacre <toby...@gmail.com> wrote:
>> >
>> > I still have a test issue but this may well just be my setup
>>
>> That's interesting, looks like it's platform dependent, possibly some
>> difference in the way setuptools is setup. What python version are you
>> using? What platform? setuptools or distutils?

[snip]

> I think this is just some interaction with some stuff in my pyenv.  I did a
> fresh install of fanstatic in a clean environment and these errors no longer
> occur.

Okay, if this issue went away I guess it's not really our fault (until
we find out that it is :).

Thanks for tracking this down.

Regards,

Martijn

[Jan-Jaap Driessen]

Looks like we fixed issue #77 . Shall I roll a release of fanstatic
with the recent fixes and pull requests in it? There are no major
changes since 0.11.4 but I would like to publish this one.

One more thing; I was thinking the following about renderers:

1) I added a print css renderer to fanstatic/core.py.

2) I was thinking about IE specific renderers like this:

class ConditionalRenderer(object):
def __init__(self, condition, renderer):
self.condition = condition
self.renderer = renderer

def __call__(self, url):
return '<!--[if %s]>%s<![endif]-->' % (self.condition,
self.renderer(url))

>>> renderer = ConditionalRenderer('lt IE 8', render_print_css)
>>> renderer('http://localhost/fanstatic/style.css')
'<!--[if lt IE 8]><link rel="stylesheet" type="text/css"
href="http://localhost/fanstatic/style.css" media="print"
/><![endif]-->'

Should this functionality be part of fanstatic?

--JJ

[Toby Dacre]

On 31 May 2012 21:33, Jan-Jaap Driessen <janjaap...@gmail.com> wrote:

On Sun, May 20, 2012 at 5:56 PM, Martijn Faassen <faa...@startifact.com> wrote:
> Hallo,
>
> On Thu, May 17, 2012 at 11:51 AM, Toby Dacre <toby...@gmail.com> wrote:
>> On 16 May 2012 19:43, Martijn Faassen <faa...@startifact.com> wrote:
>>> On Wed, May 16, 2012 at 8:00 PM, Toby Dacre <toby...@gmail.com> wrote:
>>> >
>>> > I still have a test issue but this may well just be my setup
>>>
>>> That's interesting, looks like it's platform dependent, possibly some
>>> difference in the way setuptools is setup. What python version are you
>>> using? What platform? setuptools or distutils?
> [snip]
>> I think this is just some interaction with some stuff in my pyenv.  I did a
>> fresh install of fanstatic in a clean environment and these errors no longer
>> occur.
>
> Okay, if this issue went away I guess it's not really our fault (until
> we find out that it is :).
>
> Thanks for tracking this down.

Looks like we fixed issue #77 . Shall I roll a release of fanstatic
with the recent fixes and pull requests in it? There are no major
changes since 0.11.4 but I would like to publish this one.

One more thing; I was thinking the following about renderers:

1) I added a print css renderer to fanstatic/core.py.

this seems useful
 

2) I was thinking about IE specific renderers like this:

class ConditionalRenderer(object):
   def __init__(self, condition, renderer):
       self.condition = condition
       self.renderer = renderer

   def __call__(self, url):
       return '<!--[if %s]>%s<![endif]-->' % (self.condition,
self.renderer(url))

>>> renderer = ConditionalRenderer('lt IE 8', render_print_css)
>>> renderer('http://localhost/fanstatic/style.css')
'<!--[if lt IE 8]><link rel="stylesheet" type="text/css"
href="http://localhost/fanstatic/style.css" media="print"
/><![endif]-->'

Should this functionality be part of fanstatic?

I think this would definitely be useful

Thanks once again
Toby 

--JJ

[Martijn Faassen]

Hi there,

On Thu, May 31, 2012 at 10:33 PM, Jan-Jaap Driessen
<janjaap...@gmail.com> wrote:

> 2) I was thinking about IE specific renderers like this:
>
> class ConditionalRenderer(object):
>    def __init__(self, condition, renderer):
>        self.condition = condition
>        self.renderer = renderer
>
>    def __call__(self, url):
>        return '<!--[if %s]>%s<![endif]-->' % (self.condition,
> self.renderer(url))
>
>>>> renderer = ConditionalRenderer('lt IE 8', render_print_css)
>>>> renderer('http://localhost/fanstatic/style.css')
> '<!--[if lt IE 8]><link rel="stylesheet" type="text/css"
> href="http://localhost/fanstatic/style.css" media="print"
> /><![endif]-->'
>
> Should this functionality be part of fanstatic?

I'm not sure this is high-level enough. I'm not sure where the
conditional inclusion comment hack behavior with <!--[if ..] ... -->
is defined, but right now you're abstracting out part of it, but
letting the expression definition (lt IE 8) be part of the public API
of Fanstatic.

That's an easy way to support this, but it's rather specific to this
particular way of doing conditional inclusion, too.

If you're going to do an IE specific renderer like this, why not just
call it IEConditionalRenderer? That way you're at least signaling that
this is a very specific solution, not a general one.

Regards,

Martijn

[Toby Dacre]

This seems a good approach and one I'd be keen to see.

Getting back to the subject of the thread, do you have a probable release date for the next stable version?  From my point of view we are looking to make a release of ckan that would have a fanstatic dependency in about 2-3 months time (it will likely not be in our next point release but the one following).  Is it realistic to expect the latest changes to have hit pypi by this point?

Thanks

Toby  

Regards,

Martijn

[Jan-Jaap Driessen]

On Mon, Jun 18, 2012 at 12:28 PM, Toby Dacre <toby...@gmail.com> wrote:
...

> Getting back to the subject of the thread, do you have a probable release
> date for the next stable version? From my point of view we are looking to
> make a release of ckan that would have a fanstatic dependency in about 2-3
> months time (it will likely not be in our next point release but the one
> following). Is it realistic to expect the latest changes to have hit pypi
> by this point?

I could make a 0.12 release right now if Martijn is OK with that.

--
JJ

[Toby Dacre]

t

Any update on this? It'd be nice to get the bugfixes etc on pypi

Cheers
Toby

--
JJ

[Jan-Jaap Driessen]

On Fri, Jul 27, 2012 at 10:50 AM, Toby Dacre <toby...@gmail.com> wrote:
> t
>
> On 4 July 2012 23:02, Jan-Jaap Driessen <janjaap...@gmail.com> wrote:

...

>> I could make a 0.12 release right now if Martijn is OK with that.
>>
>
> Any update on this? It'd be nice to get the bugfixes etc on pypi
>
> Cheers
> Toby

I didn't hear anything from Martijn for a while, but the changes look
solid to me so I went ahead and made a release that is now on pypi as
0.12:

http://pypi.python.org/pypi/fanstatic/0.12

--
Jan-Jaap

[Toby Dacre]

Thanks just pip installed :)
 

--
Jan-Jaap