tauruslib-devel — taurus development mailing list

[tauruslib-devel] TaurusForm custom label

[Tiago C. <tia...@es...>]

Hi,

How can I set an item label in taurusform?

Is there something like:

f = TaurusForm()
f.setModel('a/b/c/d')

f[0].setLabelWidget(Qt.QLabel('my label'))


Thanks in advance

Cheers
Tiago

[tauruslib-devel] *Call for Help* Review and integration needed.

[Carlos P. <cpa...@ce...>]

Hi all, 

Since we now have our shiny new GitHub project, we should start changing our 
minds about integration.

Until now, most of the review and integration load fell on a few people 
(mostly zibi, cfalcon, teresa and me). We have put some hopes in that the 
transition to github will help to share that load a bit more.

For non-integrators:
The idea is that *everybody* can review and comment on any of the open Pull 
Requests, even if you are not an appointed integrator. If you have looked at 
the changes from a Pull Request, please say so in a comment to the Pull 
Request. And if you think it is ready for being merged, please say so and give 
a thumbs up to the initial comment in the PR. This will help the integrators 
in their own evaluation.

For integrators:
Please subscribe (if you are not already) to notifications on new issues and 
new pull requests. When something new comes, have a look at it and if you can 
assign it to yourself and do the review and integration. If you are not sure, 
you can still comment and let someone else do the final integration. Do not 
wait for me or someone else to ask you to integrate a certain feature.

For Contributors:
If you think that someone can help in integrating your pull request, please 
use the "mention" system of github to grab that person attention (e.g. use 
@cpascual in a comment to mention me) .

So... just in order to get you people trained in the new workflows, I left a 
few Pull Requests of my own needing urgent integration. Go for them!   ;)

https://github.com/taurus-org/taurus/pulls


Cheers!

Carlos

-- 
+----------------------------------------------------+
 Carlos Pascual Izarra
 Scientific Software Coordinator
 Computing Division
 ALBA Synchrotron  [http://www.albasynchrotron.es]
 Carrer de la Llum 2-26
 E-08290 Cerdanyola del Valles (Barcelona), Spain
 E-mail: cpa...@ce...
 Phone: +34 93 592 4428
+----------------------------------------------------+

Re: [tauruslib-devel] [Tauruslib-users] Taurus moved to GitHub

[Teresa N. <mar...@de...>]

Many thanks, yes, it works now.

On 11/18/16 10:54, Carlos Pascual wrote:
> Hi Teresa, I fixed that and a few other broken links just now...
>
> Can you try again (forcing a reload of the page to avoid cache issues)?
>
>
>
> On Friday, November 18, 2016 10:46:48 AM CET Carlos Manuel Falcon Torres
> wrote:
>> Hi all,
>> It works for me.
>> Teresa, Can you access to
>> http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html ?
>>
>> Best,
>> Carlos
>>
>> On 11/18/2016 10:02 AM, Teresa Nunez wrote:
>>> Hi Carlos,
>>>
>>>                   many thanks for the information.
>>>
>>> One small thing, the link to:
>>>
>>> commit message guidelines
>>> <http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html%29>
>>>
>>> in [3] does not work, at least in my case.
>>>
>>>                  Regards,
>>>                  
>>>                                    Teresa
>>>
>>> On 11/17/16 16:14, Carlos Pascual wrote:
>>>> We are happy to announce that the Taurus project has just finished its
>>>> transition to GitHub.
>>>>
>>>> Main changes:
>>>>
>>>> - The old SourceForge Project page [1] is now considered obsolete.
>>>>
>>>> - The  official source code repository is now:
>>>>       https://github.com/taurus-org/taurus
>>>>
>>>> - The bugs and feature requests should now be reported as GitHub Issues
>>>> [2]
>>>>
>>>> - The code contribution rules changed. They are described in the
>>>>
>>>>       CONTRIBUTING.md file [3]
>>>>
>>>> For more details about the migration, see the TEP16 [4]
>>>>
>>>> References:
>>>>
>>>> [1]http://tauruslib.sourceforge.net/
>>>> [2]https://github.com/taurus-org/taurus/issues
>>>> [3]https://github.com/taurus-org/taurus/blob/develop/CONTRIBUTING.md
>>>> [4]http://www.taurus-scada.org/tep/?TEP16.md
>>> --------------------------------------------------------------------------
>>> ----
>>>
>>>
>>> _______________________________________________
>>> Tauruslib-devel mailing list
>>> Tau...@li...
>>> https://lists.sourceforge.net/lists/listinfo/tauruslib-devel
>

Re: [tauruslib-devel] [Tauruslib-users] Taurus moved to GitHub

[Carlos P. <cpa...@ce...>]

Hi Teresa, I fixed that and a few other broken links just now...

Can you try again (forcing a reload of the page to avoid cache issues)?



On Friday, November 18, 2016 10:46:48 AM CET Carlos Manuel Falcon Torres 
wrote:
> Hi all,
> It works for me.
> Teresa, Can you access to
> http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html ?
> 
> Best,
> Carlos
> 
> On 11/18/2016 10:02 AM, Teresa Nunez wrote:
> > Hi Carlos,
> > 
> >                  many thanks for the information.
> > 
> > One small thing, the link to:
> > 
> > commit message guidelines
> > <http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html%29>
> > 
> > in [3] does not work, at least in my case.
> > 
> >                 Regards,
> >                 
> >                                   Teresa
> > 
> > On 11/17/16 16:14, Carlos Pascual wrote:
> >> We are happy to announce that the Taurus project has just finished its
> >> transition to GitHub.
> >> 
> >> Main changes:
> >> 
> >> - The old SourceForge Project page [1] is now considered obsolete.
> >> 
> >> - The  official source code repository is now:
> >>      https://github.com/taurus-org/taurus
> >> 
> >> - The bugs and feature requests should now be reported as GitHub Issues
> >> [2]
> >> 
> >> - The code contribution rules changed. They are described in the
> >> 
> >>      CONTRIBUTING.md file [3]
> >> 
> >> For more details about the migration, see the TEP16 [4]
> >> 
> >> References:
> >> 
> >> [1]http://tauruslib.sourceforge.net/
> >> [2]https://github.com/taurus-org/taurus/issues
> >> [3]https://github.com/taurus-org/taurus/blob/develop/CONTRIBUTING.md
> >> [4]http://www.taurus-scada.org/tep/?TEP16.md
> > 
> > --------------------------------------------------------------------------
> > ----
> > 
> > 
> > _______________________________________________
> > Tauruslib-devel mailing list
> > Tau...@li...
> > https://lists.sourceforge.net/lists/listinfo/tauruslib-devel


-- 
+----------------------------------------------------+
 Carlos Pascual Izarra
 Scientific Software Coordinator
 Computing Division
 ALBA Synchrotron  [http://www.albasynchrotron.es]
 Carrer de la Llum 2-26
 E-08290 Cerdanyola del Valles (Barcelona), Spain
 E-mail: cpa...@ce...
 Phone: +34 93 592 4428
+----------------------------------------------------+

Re: [tauruslib-devel] [Tauruslib-users] Taurus moved to GitHub

[Teresa N. <mar...@de...>]

Hi Carlos,
                    yes, I can access the link you put here ... and now 
also the
  other one ... which goes to the same page ;).
  Thanks, somehow it works now.

                     Regards,
                                    Teresa



On 11/18/16 10:46, Carlos Manuel Falcon Torres wrote:
> Hi all,
> It works for me.
> Teresa, Can you access to 
> http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html ?
>
> Best,
> Carlos
>
> On 11/18/2016 10:02 AM, Teresa Nunez wrote:
>> Hi Carlos,
>>                  many thanks for the information.
>> One small thing, the link to:
>>
>> commit message guidelines 
>> <http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html%29>
>>
>> in [3] does not work, at least in my case.
>>
>>                 Regards,
>>                                   Teresa
>>
>> On 11/17/16 16:14, Carlos Pascual wrote:
>>> We are happy to announce that the Taurus project has just finished its
>>> transition to GitHub.
>>>
>>> Main changes:
>>>
>>> - The old SourceForge Project page [1] is now considered obsolete.
>>>
>>> - The  official source code repository is now:
>>>      https://github.com/taurus-org/taurus
>>>
>>> - The bugs and feature requests should now be reported as GitHub Issues [2]
>>>
>>> - The code contribution rules changed. They are described in the
>>>      CONTRIBUTING.md file [3]
>>>
>>> For more details about the migration, see the TEP16 [4]
>>>
>>> References:
>>>
>>> [1]http://tauruslib.sourceforge.net/
>>> [2]https://github.com/taurus-org/taurus/issues
>>> [3]https://github.com/taurus-org/taurus/blob/develop/CONTRIBUTING.md
>>> [4]http://www.taurus-scada.org/tep/?TEP16.md
>>>   
>>
>>
>>
>> ------------------------------------------------------------------------------
>>
>>
>> _______________________________________________
>> Tauruslib-devel mailing list
>> Tau...@li...
>> https://lists.sourceforge.net/lists/listinfo/tauruslib-devel
>

Re: [tauruslib-devel] [Tauruslib-users] Taurus moved to GitHub

[Carlos M. F. T. <cf...@ce...>]

Hi all,
It works for me.
Teresa, Can you access to 
http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html ?

Best,
Carlos

On 11/18/2016 10:02 AM, Teresa Nunez wrote:
> Hi Carlos,
>                  many thanks for the information.
> One small thing, the link to:
>
> commit message guidelines 
> <http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html%29>
>
> in [3] does not work, at least in my case.
>
>                 Regards,
>                                   Teresa
>
> On 11/17/16 16:14, Carlos Pascual wrote:
>> We are happy to announce that the Taurus project has just finished its
>> transition to GitHub.
>>
>> Main changes:
>>
>> - The old SourceForge Project page [1] is now considered obsolete.
>>
>> - The  official source code repository is now:
>>      https://github.com/taurus-org/taurus
>>
>> - The bugs and feature requests should now be reported as GitHub Issues [2]
>>
>> - The code contribution rules changed. They are described in the
>>      CONTRIBUTING.md file [3]
>>
>> For more details about the migration, see the TEP16 [4]
>>
>> References:
>>
>> [1]http://tauruslib.sourceforge.net/
>> [2]https://github.com/taurus-org/taurus/issues
>> [3]https://github.com/taurus-org/taurus/blob/develop/CONTRIBUTING.md
>> [4]http://www.taurus-scada.org/tep/?TEP16.md
>>   
>
>
>
> ------------------------------------------------------------------------------
>
>
> _______________________________________________
> Tauruslib-devel mailing list
> Tau...@li...
> https://lists.sourceforge.net/lists/listinfo/tauruslib-devel

Re: [tauruslib-devel] [Tauruslib-users] Taurus moved to GitHub

[Teresa N. <mar...@de...>]

Hi Carlos,
                  many thanks for the information.
One small thing, the link to:

commit message guidelines 
<http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html%29>

in [3] does not work, at least in my case.

                 Regards,
                                   Teresa

On 11/17/16 16:14, Carlos Pascual wrote:
> We are happy to announce that the Taurus project has just finished its
> transition to GitHub.
>
> Main changes:
>
> - The old SourceForge Project page [1] is now considered obsolete.
>
> - The  official source code repository is now:
>      https://github.com/taurus-org/taurus
>
> - The bugs and feature requests should now be reported as GitHub Issues [2]
>
> - The code contribution rules changed. They are described in the
>      CONTRIBUTING.md file [3]
>
> For more details about the migration, see the TEP16 [4]
>
> References:
>
> [1] http://tauruslib.sourceforge.net/
> [2] https://github.com/taurus-org/taurus/issues
> [3] https://github.com/taurus-org/taurus/blob/develop/CONTRIBUTING.md
> [4] http://www.taurus-scada.org/tep/?TEP16.md
>   

[tauruslib-devel] Taurus moved to GitHub

[Carlos P. <cpa...@ce...>]

We are happy to announce that the Taurus project has just finished its 
transition to GitHub.

Main changes:

- The old SourceForge Project page [1] is now considered obsolete. 

- The  official source code repository is now: 
    https://github.com/taurus-org/taurus

- The bugs and feature requests should now be reported as GitHub Issues [2]

- The code contribution rules changed. They are described in the
    CONTRIBUTING.md file [3]

For more details about the migration, see the TEP16 [4]

References:

[1] http://tauruslib.sourceforge.net/
[2] https://github.com/taurus-org/taurus/issues
[3] https://github.com/taurus-org/taurus/blob/develop/CONTRIBUTING.md
[4] http://www.taurus-scada.org/tep/?TEP16.md

[tauruslib-devel] Taurus ticket tracker moved to github

[Carlos P. <cpa...@ce...>]

Hi all,

As part of the preparations for migrating the Taurus project to GitHub [1], 
the ticket tracker (bug reports and feature requests) has been migrated to:

 https://github.com/taurus-org/taurus/issues

Please use this new tracker for new tickets and for updates on existing 
tickets (all tickets from SourceForge have been copied to GitHub). The old 
tracker in SourceForge will be kept read-only for historical reference only, 
and will not be updated.

Note that the GitHub issue numbers do *not* correspond to the old SourceForge 
ticket numbers and that we, unfortunately, did not add a back-link to the 
original ticket when creating the issues in GitHub. Therefore, the only way 
(for now) to link the migrated tickets to their original source is by 
searching on the title.

I hope you  enjoy the new system. If you have any comment on this migration, 
please join the discussion at [1].

Carlos

References:
[1] https://github.com/taurus-org/taurus/pull/1


-- 
+----------------------------------------------------+
 Carlos Pascual Izarra
 Scientific Software Coordinator
 Computing Division
 ALBA Synchrotron  [http://www.albasynchrotron.es]
 Carrer de la Llum 2-26
 E-08290 Cerdanyola del Valles (Barcelona), Spain
 E-mail: cpa...@ce...
 Phone: +34 93 592 4428
+----------------------------------------------------+

Re: [tauruslib-devel] Taurus Continuous Integration and Documentation (was Re: Taurus-CI)

[Vincent M. <vin...@ma...>]

> That's nice, yes... although it is more or less what you get with Docker
> (except for the admin permissions part)

Yes, though I would say conda is more about managing work environments, 
while docker focuses more on isolation:

                       Docker           conda
                       v                v
< Virtual Machine --- | --- chroot --- | --- Virtual Env >

So let's say I want to run a clean preconfigured tango database for 
testing purposes. That's where docker really shines:

$ docker run -it --publish 10000:10000 \
   tango-controls/tango-database:latest

Now I want an interactive environment where I can play with an ITango 
console, run some scripts, pop-up a taurus GUI and write a small device. 
Then conda is probably a better fit:

$ conda create --name tango --channel tango-controls \
   python=3 tango=9.2 taurus itango

> I haven't worked with caching...
> I guess you 've already looked here: https://docs.travis-ci.com/user/caching/
>
> If the above does not work,  maybe you can instruct travis to deploy your
> build objects as a tar on every successful build to some ad-hoc repo (or some
> ftp server or whatever) and then download and untar it in the  before_install
> phase. This would work both with the Travis VM directly with docker (via a
> mounted volume).

I should have been more precise :)

Caching works fine, the issue is actually related to the build itself. 
It uses the file timestamps to decide whether a build object is 
deprecated or not. So I guess I would need a way to cache the sources as 
well and compare them somehow, but it sounds hackish...

Thanks for the insight,
/Vincent

Re: [tauruslib-devel] Taurus Continuous Integration and Documentation (was Re: Taurus-CI)

[Carlos P. <cpa...@ce...>]

On Wednesday, October 26, 2016 12:01:14 PM CEST Vincent Michel wrote:
> On 10/25/2016 01:53 PM, Carlos Pascual wrote
>(...)
> >(I haven't checked, but I do not think that e.g.
> > epics and pyepics will have cunda packages).
> 
> I just checked and they're available on the lightsource2 anaconda
> channel: https://anaconda.org/lightsource2

good to know!

>  (...) It's too bad that readthedocs doesn't
> provide an API to upload the documentation directly from travis (though
> it has been discussed at some point:
> https://github.com/rtfd/readthedocs.org/issues/1083)

Yes, that would be awesome...

> Mocking is an acceptable hack for the pytango documentation since it is
> only one module to mock (tango._tango, see file [1]). 

I agree. In Taurus I worry about more dependencies, though

> Also having, the
> documentation separated from the regular build is good, since building
> the boost layer of pytango takes 10 minutes. That plus the collaborative
> features of ReadTheDocs should make it easy for people to contribute to
> the documentation, hopefully :)

I suppose this could be alleviated if you manage to setup the caching (see 
below)
 
> Now the travis builds. I am actually not so sure conda is the best
> candidate for that, docker might actually be a better choice. But conda
> is interesting for several reasons:
> 
> - it's cross platform (run transparently on all linux OS)
> - its installation doesn't require root access
> - the anaconda cloud lets you upload your own packages
> - the anaconda cloud lets you access many packages built by other users
> - the packages don't have to be python packages
> - though it integrates well with pip
> - it's very simple to manage several environments with specific packages
> - it's very simple to build and upload packages to anaconda
> - conda-forge can build and upload packages for all platforms on its own
> channel

I definitely need to learn more about conda... Johan Forsberg already sold me 
some of those points last week ;)

> 
> That means in the future, you might be able to run:
> 
> $ conda create --channel conda-forge --name tango python=3 taurus
> 
> to create a tango-ready environment with taurus and python3 that works
> on any platform, from scratch, without admin rights and without building
> anything like pip would do. We're not here yet, but I would like to see
> conda becoming the default solution for tutorial, trainings, short-term
> clients, etc.

That's nice, yes... although it is more or less what you get with Docker 
(except for the admin permissions part)

> 
> Now back to the builds. One issue is that travis doesn't provide any
> integrated support for conda, like it does with docker. That means conda
> needs to be installed from scratch (see the pytango travis file [2]).
> Also, it would be nice for travis to support anaconda as a deployment
> provider. But otherwise, it works fine.
> 
> To conclude, I don't think docker and conda are mutually exclusive since
> we'll keep building platform-specific packages anyway. So I'd say it's
> good that we keep working on providing more resources for both technologies.

I agree, in some cases, I would consider useful even to use Conda within a 
docker...
Besides, even if we base our solution on docker, I think we should automate 
the deployment of Conda  packages...

> 
> I have additional question regarding docker. One thing that I'd like to
> do in travis is to cache the build objects so that the boost layer
> doesn't build every time, but only if something changed on the boost
> side (which is pretty rare). Do you know if there is a way to achieve
> that using travis and/or docker capabilities?

I haven't worked with caching... 
I guess you 've already looked here: https://docs.travis-ci.com/user/caching/

If the above does not work,  maybe you can instruct travis to deploy your 
build objects as a tar on every successful build to some ad-hoc repo (or some 
ftp server or whatever) and then download and untar it in the  before_install 
phase. This would work both with the Travis VM directly with docker (via a 
mounted volume).

Well, thanks for all the food for thought. Let's keep this flowing...

Cheers!

Carlos


-- 
+----------------------------------------------------+
 Carlos Pascual Izarra
 Scientific Software Coordinator
 Computing Division
 ALBA Synchrotron  [http://www.albasynchrotron.es]
 Carrer de la Llum 2-26
 E-08290 Cerdanyola del Valles (Barcelona), Spain
 E-mail: cpa...@ce...
 Phone: +34 93 592 4428
+----------------------------------------------------+

[tauruslib-devel] TEP16: Moving Taurus to GitHub

[Carlos P. <cpa...@ce...>]

Hi all,

I just created a DRAFT for a new Taurus Enhancement Proposal about 
moving Taurus to GitHub. Here is the TEP header:

~~~~
Title: Moving Taurus to GitHub
TEP: 16
State: DRAFT
Date: 2016-10-21
Drivers: Carlos Pascual-Izarra cpa...@ce...
URL: https://github.com/cpascual/taurus/blob/tep16/doc/source/tep/TEP16.md
License: http://www.jclark.com/xml/copying.txt
Abstract: Move Taurus project from its current hosting in SourceForge to 
 GitHub. The move affects the code repository, the ticket tracker and the 
 wiki pages. It also proposes to change the contribution and the TEP 
 workflow to make use of the Pull Request feature.
~~~~

As you can see, the TEP16 text can be reached at:

https://github.com/cpascual/taurus/blob/tep16/doc/source/tep/TEP16.md

Also note that the changes proposed in TEP16 are already partially implemented 
for evaluation purposes in the following repository:

https://github.com/taurus-org/taurus

Also note that, according to the proposed new workflow, the following Pull 
Request has been created for discussing the TEP16:

https://github.com/taurus-org/taurus/pull/1

I suggest that we use the mentioned Pull Request as the main channel for 
discussion, since it will be a good way for validating the proposed workflow.

Carlos

-- 
+----------------------------------------------------+
 Carlos Pascual Izarra
 Scientific Software Coordinator
 Computing Division
 ALBA Synchrotron  [http://www.albasynchrotron.es]
 Carrer de la Llum 2-26
 E-08290 Cerdanyola del Valles (Barcelona), Spain
 E-mail: cpa...@ce...
 Phone: +34 93 592 4428
+----------------------------------------------------+

Re: [tauruslib-devel] Taurus Continuous Integration and Documentation (was Re: Taurus-CI)

[Vincent M. <vin...@ma...>]

On 10/25/2016 01:53 PM, Carlos Pascual wrote
> Note: this is a reply to a private email from Vincent Michel, but it touches a
> topic that I wanted to open for public discussion, so I CC'ed the taurus-devel
> list. Vincent: I hope you do not mind it...

No problem!

> Now, with the Conda support (and with the work you did in getting the stack
> for PyTango in Conda), I guess we could get rid of most of the mocks, but
> probably not all of them (I haven't checked, but I do not think that e.g.
> epics and pyepics will have cunda packages).

I just checked and they're available on the lightsource2 anaconda 
channel: https://anaconda.org/lightsource2

> And, since we *plan* to use Travis for Continuous Deployment of packages, it
> seems natural to make the docs just another artifact from the Travis builds
> and have them delivered to e.g. github pages or pythonhosted, or wherever.
> Building the docs in Travis with docker also has the advantage of considering
> the success in building the docs as one more test during the CI.

Yes that makes a lot of sense. It's too bad that readthedocs doesn't 
provide an API to upload the documentation directly from travis (though 
it has been discussed at some point: 
https://github.com/rtfd/readthedocs.org/issues/1083)

> - For us, the main reason for going "the docker way" is that it enables us to
> introduce CI tests for configurations that closely match those used by
> different institutions: e.g. if MaxIV was interested in having every commit
> tested on  a system like the ones used in production, all that would be
> required would be for MaxIV to provide the link to a suitable  container in
> dockerhub. This way we could create a large set of test environments while
> keeping the maintenance work distributed (each interested party provides and
> updates its own container(s)).

That's a very good point!

> I hope I managed to cover your questions. Now I would be very interested in
> learning about your reasons, choices and concerns as well. I am sure there is
> a lot of experience than we can share.

Thanks for the thorough reply. In the case of pytango we're still 
experimenting, though the readthedocs + mock and travis + conda 
solutions seem to be promising.

Mocking is an acceptable hack for the pytango documentation since it is 
only one module to mock (tango._tango, see file [1]). Also having, the 
documentation separated from the regular build is good, since building 
the boost layer of pytango takes 10 minutes. That plus the collaborative 
features of ReadTheDocs should make it easy for people to contribute to 
the documentation, hopefully :)

Now the travis builds. I am actually not so sure conda is the best 
candidate for that, docker might actually be a better choice. But conda 
is interesting for several reasons:

- it's cross platform (run transparently on all linux OS)
- its installation doesn't require root access
- the anaconda cloud lets you upload your own packages
- the anaconda cloud lets you access many packages built by other users
- the packages don't have to be python packages
- though it integrates well with pip
- it's very simple to manage several environments with specific packages
- it's very simple to build and upload packages to anaconda
- conda-forge can build and upload packages for all platforms on its own 
channel

That means in the future, you might be able to run:

$ conda create --channel conda-forge --name tango python=3 taurus

to create a tango-ready environment with taurus and python3 that works 
on any platform, from scratch, without admin rights and without building 
anything like pip would do. We're not here yet, but I would like to see 
conda becoming the default solution for tutorial, trainings, short-term 
clients, etc.

Now back to the builds. One issue is that travis doesn't provide any 
integrated support for conda, like it does with docker. That means conda 
needs to be installed from scratch (see the pytango travis file [2]). 
Also, it would be nice for travis to support anaconda as a deployment 
provider. But otherwise, it works fine.

To conclude, I don't think docker and conda are mutually exclusive since 
we'll keep building platform-specific packages anyway. So I'd say it's 
good that we keep working on providing more resources for both technologies.

I have additional question regarding docker. One thing that I'd like to 
do in travis is to cache the build objects so that the boost layer 
doesn't build every time, but only if something changed on the boost 
side (which is pretty rare). Do you know if there is a way to achieve 
that using travis and/or docker capabilities?

Thanks,
/Vincent


[1] 
https://github.com/tango-cs/pytango/blob/master/doc/mock_tango_extension.py
[2] https://github.com/tango-cs/pytango/blob/develop/.travis.yml

Re: [tauruslib-devel] TEP15: fragment-based slicing support in URIs

[Teresa N. <mar...@de...>]

Hi Carlos,
                   thanks for the explanation. Yes, that changes my
  opinion, the first option would be then also fine for me.

                           Regards,
                                          Teresa

On 10/25/16 15:34, Carlos Pascual wrote:
> On Monday, October 24, 2016 9:30:19 AM CEST Teresa Nunez wrote:
>> Hi Carlos,
>>   I think I would avoid the first of the solutions
>> because it can
>>    be confusing if one has to use the 'percent' ... it would not be 'natural'
>> any more.
> Hi Teresa, thanks for your feedback.
>
> Just  one comment: note that, as with web browsers, the user does not need to
> be forced to use % . We may leave that job to the validator, and deal with it
> internally. Also, we could even decide to not care at all about brackets being
> forbidden by  RFC3986 and use them anyway without escaping them (as of now,
> that would not present any technical problem, only a formal one)
>
> With this I am not pushing for this option, just stating that we could still
> consider it.
>
> Cheers!
>

Re: [tauruslib-devel] TEP15: fragment-based slicing support in URIs

[Carlos P. <cpa...@ce...>]

On Monday, October 24, 2016 9:30:19 AM CEST Teresa Nunez wrote:
> Hi Carlos,
>  I think I would avoid the first of the solutions
> because it can
>   be confusing if one has to use the 'percent' ... it would not be 'natural'
> any more. 

Hi Teresa, thanks for your feedback.

Just  one comment: note that, as with web browsers, the user does not need to 
be forced to use % . We may leave that job to the validator, and deal with it 
internally. Also, we could even decide to not care at all about brackets being 
forbidden by  RFC3986 and use them anyway without escaping them (as of now, 
that would not present any technical problem, only a formal one)

With this I am not pushing for this option, just stating that we could still 
consider it.

Cheers!

-- 
+----------------------------------------------------+
 Carlos Pascual Izarra
 Scientific Software Coordinator
 Computing Division
 ALBA Synchrotron  [http://www.albasynchrotron.es]
 Carrer de la Llum 2-26
 E-08290 Cerdanyola del Valles (Barcelona), Spain
 E-mail: cpa...@ce...
 Phone: +34 93 592 4428
+----------------------------------------------------+

[tauruslib-devel] Taurus Continuous Integration and Documentation (was Re: Taurus-CI)

[Carlos P. <cpa...@ce...>]

Hi,

Note: this is a reply to a private email from Vincent Michel, but it touches a 
topic that I wanted to open for public discussion, so I CC'ed the taurus-devel 
list. Vincent: I hope you do not mind it...

On Tuesday, October 25, 2016 10:29:05 AM CEST Vincent Michel wrote:
> Last week, the solaris guys told me you were planning to move the taurus
> documentation from readthedocs to github-pages. I'm a bit surprised
> since I've been very satisfied with readthedocs so far.

The reason we were dissatisfied with readthedocs is mainly that we have to 
maintain mocks for many of our dependencies: when we started, there was no 
conda support, so we were forced to develop mocks for many of our dependencies 
(PyQt, Tango, ...). 

For this we developed the <taurus>/doc/buildmock.py script. And since we were 
at it, we also included several other modules (even if they were pip-
installable) in order to save build time (e.g. numpy,...). The buildmock.py 
basically creates a zip with mock modules that, when inserted into the 
pythonpath, allows us to build the docs.

This solution "sort of works"  but it is a PITA when one wants to update or 
change a dependency because usually some manual tweaking (and therefore 
testing) is required.

Now, with the Conda support (and with the work you did in getting the stack 
for PyTango in Conda), I guess we could get rid of most of the mocks, but 
probably not all of them (I haven't checked, but I do not think that e.g. 
epics and pyepics will have cunda packages).

I am also concerned in that, when we finally manage to provide proper plugin 
support and third parties start providing plugins for Taurus (e.g. a new 
scheme for some exotic control system), we will need to support more 
dependencies if we want to document the new additions. And  the odds of them 
being available as Conda packages is less than them being installable in a 
Docker container.

Furthermore, we *already* have docker containers with all the dependencies 
installed [1,2], since we use them for Travis-CI (more about this later). 
Also, the work of having the container updated with new dependencies will need 
to be done anyway because we will want to run automated tests on the new 
features as well.

And, since we *plan* to use Travis for Continuous Deployment of packages, it 
seems natural to make the docs just another artifact from the Travis builds 
and have them delivered to e.g. github pages or pythonhosted, or wherever.

Building the docs in Travis with docker also has the advantage of considering 
the success in building the docs as one more test during the CI.

Finally, one extra advantage that I see from the Docker approach is that 
debugging problems in the doc build becomes simpler, since you can run locally 
exactly the same container that Travis is using.

Note that the ideal solution for us would be that ReadTheDocs supported 
dockers..., but we approached the guy behind RTD and he said that this would 
not be the case in a near future (he said they may use docker containers 
internally to provide some customised machines, but are not considering for 
now giving users the possibility of running their own containers)

Note: If I get some possitive feedback for this option, I could write a TEP...


> Also, I've been working on the pytango CI for the last few months and
> since our projects are quite similar, I thought it would be good to
> compare our CI solutions. Taurus seems to embrace docker while pytango
> is using conda environments, so I'd like to hear about your view on that
> matter ;)

Regarding the use of Docker in Travis instead of using conda directly on top 
of the native Ubuntu  VM provided by Travis, here are some reasons:

- For us, the main reason for going "the docker way" is that it enables us to 
introduce CI tests for configurations that closely match those used by 
different institutions: e.g. if MaxIV was interested in having every commit 
tested on  a system like the ones used in production, all that would be 
required would be for MaxIV to provide the link to a suitable  container in 
dockerhub. This way we could create a large set of test environments while 
keeping the maintenance work distributed (each interested party provides and 
updates its own container(s)).

- Another practical advantage: we can use the same containers outside of 
Travis for our own work: e.g. for debugging, for demos, for running local 
tests in a well-controlled environment, and even for packaging or for running 
internal CI servers with jenkins. The debugging aspect is specially 
interesting: if a user reports a difficult-to-reproduce bug, you can ask him/
her to reproduce it on one of the "official" containers. 

- One aspect that may also be interesting for PyTango (and certainly for 
Taurus): with docker, you can instantiate more than one container in a single 
run and do tests where network communication plays a role. We haven't got 
there yet, but it seems important.

- Also, I think I read that Travis wanted to encourage docker-based  builds, 
even by giving you some more resources if you used Docker... but I cannot find 
a link for that, so maybe I dreamt it...

I hope I managed to cover your questions. Now I would be very interested in 
learning about your reasons, choices and concerns as well. I am sure there is 
a lot of experience than we can share.

Cheers, 

Carlos

[1] https://hub.docker.com/r/cpascual/taurus-test/
[2] https://hub.docker.com/r/reszelaz/sardana-test/

-- 
+----------------------------------------------------+
 Carlos Pascual Izarra
 Scientific Software Coordinator
 Computing Division
 ALBA Synchrotron  [http://www.albasynchrotron.es]
 Carrer de la Llum 2-26
 E-08290 Cerdanyola del Valles (Barcelona), Spain
 E-mail: cpa...@ce...
 Phone: +34 93 592 4428
+----------------------------------------------------+

Re: [tauruslib-devel] TEP15: fragment-based slicing support in URIs

[Teresa N. <mar...@de...>]

Hi Carlos,
                 I think I would avoid the first of the solutions 
because it can
  be confusing if one has to use the 'percent' ... it would not be 'natural'
  any more. For the other two at least one knows from the beginning that
  they are 'artificial' and one has to learn the way the slicing has to be
  done ... Between those I do not have any preference, perhaps the last one
  is faster to use.
  Well, only my opinion, in any case any of them would be fine. Thanks.

                                    Regards,
                                                      Teresa



On 10/24/16 08:31, Carlos Pascual wrote:
> *bump*
>
> Hello?
>
> Anybody there?
>
> No opinions on this?
>
> On Monday, June 27, 2016 4:08:17 PM CEST Carlos Pascual wrote:
>> Hi all,
>>
>> I just created a draft for a new Taurus Enhancement Proposal about
>> supporting slicing in taurus URIs.
>>
>> Please have a look at it:
>>
>> https://sourceforge.net/p/tauruslib/wiki/TEP15/
>>
>> And please contribute your thoughts by replying to this thread.
>>
>>
>> Cheers,
>>
>> Carlos
>

Re: [tauruslib-devel] TEP15: fragment-based slicing support in URIs

[Carlos P. <cpa...@ce...>]

*bump*

Hello?

Anybody there?

No opinions on this?

On Monday, June 27, 2016 4:08:17 PM CEST Carlos Pascual wrote:
> Hi all,
> 
> I just created a draft for a new Taurus Enhancement Proposal about
> supporting slicing in taurus URIs.
> 
> Please have a look at it:
> 
> https://sourceforge.net/p/tauruslib/wiki/TEP15/
> 
> And please contribute your thoughts by replying to this thread.
> 
> 
> Cheers,
> 
> Carlos


-- 
+----------------------------------------------------+
 Carlos Pascual Izarra
 Scientific Software Coordinator
 Computing Division
 ALBA Synchrotron  [http://www.albasynchrotron.es]
 Carrer de la Llum 2-26
 E-08290 Cerdanyola del Valles (Barcelona), Spain
 E-mail: cpa...@ce...
 Phone: +34 93 592 4428
+----------------------------------------------------+

Re: [tauruslib-devel] [PATCH] Fix bug-333: ActiveMntGrp using uppercase

[Carlos P. <cpa...@ce...>]

Applied to support-3.x and develop branches.

On martes, 23 de agosto de 2016 15:22:21 (CEST) Zbigniew Reszela wrote:
> From: zreszela <zre...@ce...>
> 
> "MntGrpConfigs" is of CaselessDict type which maintains keys in lowercase.
> However the "ActiveMntGrp" maintains the case sensitivity. Compare these two
> using the CaselessDict.__contains__ implementation (using the in operator
> for the dictionary instead of its list of keys).
> ---
>  lib/taurus/qt/qtgui/taurusgui/macrolistener.py | 9 +++++----
>  1 file changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/lib/taurus/qt/qtgui/taurusgui/macrolistener.py
> b/lib/taurus/qt/qtgui/taurusgui/macrolistener.py index 359eedb..fb4f63d
> 100644
> --- a/lib/taurus/qt/qtgui/taurusgui/macrolistener.py
> +++ b/lib/taurus/qt/qtgui/taurusgui/macrolistener.py
> @@ -119,14 +119,15 @@ class DynamicPlotManager(Qt.QObject,
> TaurusBaseComponent): QDoor.getExperimentDescription`
>                          for more details
>          '''
> -        if expconf['ActiveMntGrp'] is None:
> +        activeMntGrp = expconf['ActiveMntGrp']
> +        if activeMntGrp is None:
>              return
> -        if expconf['ActiveMntGrp'] not in expconf['MntGrpConfigs'].keys():
> +        if activeMntGrp not in expconf['MntGrpConfigs']:
>              self.warning(
>                  "ActiveMntGrp '%s' is not defined" %
> -                expconf['ActiveMntGrp'])
> +                activeMntGrp)
>              return
> -        mgconfig = expconf['MntGrpConfigs'][expconf['ActiveMntGrp']]
> +        mgconfig = expconf['MntGrpConfigs'][activeMntGrp]
>          channels = dict(getChannelConfigs(mgconfig, sort=False))
> 
>          #classify by type of plot:


-- 
+----------------------------------------------------+
 Carlos Pascual Izarra
 Scientific Software Coordinator
 Computing Division
 ALBA Synchrotron  [http://www.albasynchrotron.es]
 Carrer de la Llum 2-26
 E-08290 Cerdanyola del Valles (Barcelona), Spain
 E-mail: cpa...@ce...
 Phone: +34 93 592 4428
+----------------------------------------------------+

[tauruslib-devel] [PATCH] Fix bug-333: ActiveMntGrp using uppercase

[Zbigniew R. <zre...@ce...>]

From: zreszela <zre...@ce...>

"MntGrpConfigs" is of CaselessDict type which maintains keys in lowercase.
However the "ActiveMntGrp" maintains the case sensitivity. Compare these two
using the CaselessDict.__contains__ implementation (using the in operator for
the dictionary instead of its list of keys).
---
 lib/taurus/qt/qtgui/taurusgui/macrolistener.py | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/lib/taurus/qt/qtgui/taurusgui/macrolistener.py b/lib/taurus/qt/qtgui/taurusgui/macrolistener.py
index 359eedb..fb4f63d 100644
--- a/lib/taurus/qt/qtgui/taurusgui/macrolistener.py
+++ b/lib/taurus/qt/qtgui/taurusgui/macrolistener.py
@@ -119,14 +119,15 @@ class DynamicPlotManager(Qt.QObject, TaurusBaseComponent):
                         QDoor.getExperimentDescription` 
                         for more details 
         '''
-        if expconf['ActiveMntGrp'] is None:
+        activeMntGrp = expconf['ActiveMntGrp']
+        if activeMntGrp is None:
             return
-        if expconf['ActiveMntGrp'] not in expconf['MntGrpConfigs'].keys():
+        if activeMntGrp not in expconf['MntGrpConfigs']:
             self.warning(
                 "ActiveMntGrp '%s' is not defined" %
-                expconf['ActiveMntGrp'])
+                activeMntGrp)
             return
-        mgconfig = expconf['MntGrpConfigs'][expconf['ActiveMntGrp']]
+        mgconfig = expconf['MntGrpConfigs'][activeMntGrp]
         channels = dict(getChannelConfigs(mgconfig, sort=False))
         
         #classify by type of plot:
-- 
1.8.4.5

[tauruslib-devel] Solution without casting to lowercase

[Zbigniew R. <zre...@ce...>]

As commented by Carlos in https://sourceforge.net/p/tauruslib/tickets/333/#edb1/983e/d761
the solution does not require casting to lowercase. In continuation please find
the new patch. I applies well to the support-3.x branch. In order to apply it
to the develop branch one must use -3 option e.g. "git am -3 0001-....patch".

[tauruslib-devel] [PATCH] Fix bug-333: compare meas. groups in lowercase

[Zbigniew R. <zre...@ce...>]

From: zreszela <zre...@ce...>

ExperimentConfiguration dict contains "MntGrpConfigs" with meas. group names
casted to lowercase (CaselessDict) but "ActiveMntGrp" may contain uppercase.
Thus cast the latter one to lowercase for proper comparison.
---
 lib/taurus/qt/qtgui/taurusgui/macrolistener.py | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/lib/taurus/qt/qtgui/taurusgui/macrolistener.py b/lib/taurus/qt/qtgui/taurusgui/macrolistener.py
index 359eedb..9e8e038 100644
--- a/lib/taurus/qt/qtgui/taurusgui/macrolistener.py
+++ b/lib/taurus/qt/qtgui/taurusgui/macrolistener.py
@@ -119,14 +119,16 @@ class DynamicPlotManager(Qt.QObject, TaurusBaseComponent):
                         QDoor.getExperimentDescription` 
                         for more details 
         '''
-        if expconf['ActiveMntGrp'] is None:
+        activeMntGrp = expconf['ActiveMntGrp']
+        if activeMntGrp is None:
             return
-        if expconf['ActiveMntGrp'] not in expconf['MntGrpConfigs'].keys():
+        activeMntGrpLower = activeMntGrp.lower()
+        if activeMntGrpLower not in expconf['MntGrpConfigs'].keys():
             self.warning(
                 "ActiveMntGrp '%s' is not defined" %
-                expconf['ActiveMntGrp'])
+                activeMntGrp)
             return
-        mgconfig = expconf['MntGrpConfigs'][expconf['ActiveMntGrp']]
+        mgconfig = expconf['MntGrpConfigs'][activeMntGrpLower]
         channels = dict(getChannelConfigs(mgconfig, sort=False))
         
         #classify by type of plot:
-- 
1.8.4.5

[tauruslib-devel] Patch for bug-333 (related to Sardana bug-498)

[Zbigniew R. <zre...@ce...>]

Hello,

I'm sending an improved solution proposed by Daniel in:
https://sourceforge.net/p/tauruslib/tickets/333/#edb1
This one is prepared for support-3.x branch. If there are no negative comments
I will apply it for both support-3.x and develop.

Cheers,
Zibi

Re: [tauruslib-devel] Taurus and GIL

[Carlos P. <cpa...@ce...>]

Hi, just in case someone stumbles into this who is not in the Tango List, see the very complete 
reply from Tiago in the Tango list:

On Mon 8 August 2016 09:41:27 coutinho wrote:
> Hi Giacomo,
> 
> On 07/28/2016 05:29 PM, Giacomo S. wrote:
> > Hello Carlos,
> > 
> > I have a technical question concerning Taurus and Python GIL.
> > How is multi threading managed inside Taurus?
> > Once I had a talk with Tiago about this topic and, as far as I can
> > remember, he said that, where required, the
> > GIL is somehow disabled by Taurus in order to achieve real multi
> > threaded behaviour (real POSIX/Windows threads).
> 
> The  GIL only needs to be managed by PyTango (not taurus) because this
> is where the blocking network calls occur.
> Basically, in every place PyTango calls a Tango C++ I/O blocking call,
> it releases the GIL so that other threads that may execute python
> code are not blocked.
> 
> > Could you please confirm this and, consequently, claim that Taurus
> > threads are really concurrent threads?
> 
> Taurus is based on the concept of pluggable Control Systems. By this I
> mean it can work with Tango, Epics or other third-party control
> systems. If the taurus plug-in that is written for a specific control
> system happens to block the thread there is nothing that taurus can
> do about it. It all depends on how the plug-in and the third-party
> libraries are written. For the case of Tango I can tell you that the
> PyTango library manages the GIL properly.
> 
> > Second question. In a situation where a third party library relies
> > on
> > the GIL (being enabled), is there any
> > concurrency issue potentially introduced when the same library
> > operates in a context where the GIL is disabled?
> 
> Since taurus does not handle the GIL by itself it does not generate
> any concurrency issue.
> 
> > Gracias, Giacomo.
> 
> Thanks Giacomo for your pertinent questions. It is important that in
> the context of a distributed (potentially blocking) control system,
> we understand what happens in python with the GIL, who has the
> responsibility to manage it and where blocking may occur.
> 
> In the case of Tango, it should be the library that handles Tango
> (PyTango) who abstracts the underlying complexities of multi-threaded,
> I/O blocking control system.
> 
> Taurus does not take care of the GIL because it trusts that the
> blocking library does it well. Having said that, taurus does create a
> pool of threads that poll the underlying attributes (tango or other)
> in an old style attempt to paralyze blocking I/O calls.
> We choose threads in taurus because at the time PyTango was not
> coroutine friendly. Probably if it was done today we would have used
> another simpler, lighter mechanism (like gevent or asyncio).
> 
> Hope it helps,
> 
> Cheers
> Tiago




-- 
+----------------------------------------------------+
 Carlos Pascual Izarra
 Scientific Software Coordinator
 Computing Division
 ALBA Synchrotron  [http://www.albasynchrotron.es]
 Carrer de la Llum 2-26
 E-08290 Cerdanyola del Valles (Barcelona), Spain
 E-mail: cpa...@ce...
 Phone: +34 93 592 4428
+----------------------------------------------------+

Re: [tauruslib-devel] Taurus and GIL

[Carlos M. F. T. <cf...@ce...>]

Hi Giacomo,
Sorry for the late answer.
As far I know taurus does not use GIL. Taurus manages the multi 
threading in the taurusmanager class.
It class is configured by default to use concurrent threads, but it 
changes at the scheme level where the elements set it to serial instead 
by default. So, you have to explicit set the Serialization mode to 
concurrent.

e.g.

    importtaurus
    fromtaurus.core.taurusbasetypesimportTaurusSerializationMode

    a = taurus.Attribute('tango:sys/tg_test/1/short_scalar')
    a.setSerializationMode(TaurusSerializationMode.Concurrent)



For your second question, I guess you should not have problems with 
Taurus but I don't know if PyTango is affected.

Sorry for the ambiguous answer, I added the taurus list to see if 
someone else can help you.

Best,
Carlos F.



On 07/28/2016 05:29 PM, Giacomo S. wrote:
> Hello Carlos,
>
> I have a technical question concerning Taurus and Python GIL.
> How is multi threading managed inside Taurus?
> Once I had a talk with Tiago about this topic and, as far as I can
> remember, he said that, where required, the
> GIL is somehow disabled by Taurus in order to achieve real multi
> threaded behaviour (real POSIX/Windows threads).
>
> Could you please confirm this and, consequently, claim that Taurus
> threads are really concurrent threads?
>
> Second question. In a situation where a third party library relies on
> the GIL (being enabled), is there any
> concurrency issue potentially introduced when the same library operates
> in a context where the GIL is disabled?
>
> Gracias, Giacomo.